The purpose of this change is to shift the focus from Jobs to Tasks in terms of maintaining state, configuration, execution and monitoring.
This enables multiple Task Payloads to be associated with a single Job. The Job's Task function can then be run multiple times, taking in a different Payload each time.
Each Payload now becomes the single unit that we wish to maintain state for independently, rather than the Job.
Each Task-Payload combination can now be executed concurrently, in parallel to the other Task-Payload combinations within the same Job, as well as any other Jobs.
Other changes include:
Make delay/interval between Task runs configurable on a per-Task basis. Also randomise this slightly, between an upper/lower bound that is determined by a numeric global offset either side of the task interval (e.g. +/- 7 seconds).
Configure Task bypass as a timestamp rather than a boolean. This enables a Task to be bypassed for a specific duration of time, rather than indefinitely until a new Task State file takes over (i.e. the next day)
The purpose of this change is to shift the focus from Jobs to Tasks in terms of maintaining state, configuration, execution and monitoring.
This enables multiple Task Payloads to be associated with a single Job. The Job's Task function can then be run multiple times, taking in a different Payload each time.
Each Payload now becomes the single unit that we wish to maintain state for independently, rather than the Job.
Each Task-Payload combination can now be executed concurrently, in parallel to the other Task-Payload combinations within the same Job, as well as any other Jobs.
Other changes include: