vdbergh

What I am saying is that a finished test does not hand out tasks, even if `run["finished"]` happens to be `False` for some reason. So in my universe, the first...

Still I don't see how it can happen. If the worker gets an exception executing `api_stop_run` (e.g. because of a connection problem), I don't think it will retry the api...

What you are saying seems possible, although it requires the collusion of two events, which seem already unlikely by themselves: an invalid bench and a network outage. Although it does...

It seems `failed_task` currently does not write an action. This counts as a bug I think.

You are right. It seems that all `failed_task` does is to set `task["active"]=False` (this means no worker is working on this task). It does not mean failure. So `failed_task` is...

Still I wonder if `failed_task` is actually called after successful completion of the task. It should execute the following statement ``` print( "Inactive: https://tests.stockfishchess.org/tests/view/{} {} {}".format( run_id, task if DEBUG...

But ``` print( "Inactive: https://tests.stockfishchess.org/tests/view/{} {} {}".format( run_id, task if DEBUG else task_id, worker_name(task["worker_info"]) ), flush=True, ) ``` in `rundb.py:failed_task()` should always be executed. It does not depend on `DEBUG=True`.

Ok. I guess it would be better to call it `stop_task`. With a message in actiondb if the task finished uncleanly.

It may be due to some changes of mine. I think most invocations now end in this ``` if not task["active"]: print("Failed_task: task {} is not active".format(task_id), flush=True) return {"task_alive":...

In other words. Calling `failed_task` after a task that completed normally is harmless but also useless.