Currently when scheduling a task with ETA, the task is transmitted to the worker (=robot) immediately
But if the robot has a problem or something between the moment when it is sent, and the moment when the task is supposed to be executed, there is a lot of "unexpected things" that can happen, like the task being run when you expect it to be cancelled, or the opposite...
We should have a scheduler with a more deterministic behavior, even when the final worker status is very undeterministic (hard shutdown, network disconnection for a long time, etc.)
-> The idea is to simplify the "beat" mechanism, and move the "scheduler" (deciding to which robot we need to assign which task and when) to a usual worker on the server (always connected).
If done well, this would allow simpler supervision of tasks currently scheduled, and possibility to cancel and so on... => we will send to the robot only at the last moment.
Currently when scheduling a task with ETA, the task is transmitted to the worker (=robot) immediately
But if the robot has a problem or something between the moment when it is sent, and the moment when the task is supposed to be executed, there is a lot of "unexpected things" that can happen, like the task being run when you expect it to be cancelled, or the opposite...
We should have a scheduler with a more deterministic behavior, even when the final worker status is very undeterministic (hard shutdown, network disconnection for a long time, etc.)
-> The idea is to simplify the "beat" mechanism, and move the "scheduler" (deciding to which robot we need to assign which task and when) to a usual worker on the server (always connected).
If done well, this would allow simpler supervision of tasks currently scheduled, and possibility to cancel and so on... => we will send to the robot only at the last moment.