Currently the controller has two situations where it can end it's execution with:
Execution was successful so the ejector function (jobDone) is called
Execution was not successful, so no signals are sent to the system (with the assumption that the runner will retry the task later if needed)
Sometimes it might be beneficial to have the option to disable a task (just like the runner does). One possible scenario for this might be for example when the controller receives a WORK_FAIL from the worker with an adjacent WORK_WARNING that the payload could not be processed properly by the worker and subsequent tries would not result in completion.
I think we could maybe use the same eject task for this purpose, with just an additional keyword present in the task definition. So in addition to the "id" keyword, the controller could also specify something like a "eject_mode" keyword with the value "disable" to indicate that the task should not be cleared but should be disabled instead.
In addition to this it might also be beneficial for some controller implementations to actually completely alter the task object in the persistent storage in response to some execution results.
If we want to go this far, it might be a good idea to just skip the previous step and actually just introduce a new reserved work for the task definition: "state". This state would then be used to indicate that the task is either enabled, disabled or done. This would allow us to simplify the adapter interface so that there would not be different adapter interfaces for "update", "disable" or "eject" - there would just be one "updateTask" which would act a bit differently if the "state" is set as "disabled" or "done".
The benefits of this would be that also the runner could use a similar interface to indicate "disabling" a task, which would simplify the adapter interface even further.
This would however make it a bit harder for controllers to actually do the most common eject tasks and we would probably get some interesting race condition problems if multiple controllers were to execute and then try to update the same task. For this reason I would probably think about this feature a lot more before actually implementing it.
Currently the controller has two situations where it can end it's execution with:
Sometimes it might be beneficial to have the option to disable a task (just like the runner does). One possible scenario for this might be for example when the controller receives a WORK_FAIL from the worker with an adjacent WORK_WARNING that the payload could not be processed properly by the worker and subsequent tries would not result in completion.
I think we could maybe use the same eject task for this purpose, with just an additional keyword present in the task definition. So in addition to the "id" keyword, the controller could also specify something like a "eject_mode" keyword with the value "disable" to indicate that the task should not be cleared but should be disabled instead.
In addition to this it might also be beneficial for some controller implementations to actually completely alter the task object in the persistent storage in response to some execution results.
If we want to go this far, it might be a good idea to just skip the previous step and actually just introduce a new reserved work for the task definition: "state". This state would then be used to indicate that the task is either enabled, disabled or done. This would allow us to simplify the adapter interface so that there would not be different adapter interfaces for "update", "disable" or "eject" - there would just be one "updateTask" which would act a bit differently if the "state" is set as "disabled" or "done".
The benefits of this would be that also the runner could use a similar interface to indicate "disabling" a task, which would simplify the adapter interface even further.
This would however make it a bit harder for controllers to actually do the most common eject tasks and we would probably get some interesting race condition problems if multiple controllers were to execute and then try to update the same task. For this reason I would probably think about this feature a lot more before actually implementing it.