I would like for the scheduled task configuration to be part of the app configuration, not to be part of a particular branch.
I would also like to add a Notes field on each scheduled task.
The UI to schedule a task could be similar to this:
And something like this to list them:
Notice that task_1 runs on two environments, while task_2 and delete_expired_pdf run each on its own environment.
The reason why I don’t like the current implementation is that:
- It would be easy to configure what tasks run on what environments and have have specific tasks running in specific environments (see snapshots above)
- The merge from
dev to prod messing up the scheduled tasks that are already working well in prod is scary:
- The current framework, where something is set in a branch and something is set at app level, is confusing (see here)
EDIT
- It would be easy to get the picture of what is scheduled to run. Right now you need to check each branch out one by one
How would you specify that Customer 1, using Environment 1, and Database 1, wants their Task A to run every 6 hours, while Customer 2 (Env 2, Db 2), wants their Task A to run every 2 days?
The association between database and environment is done in the environment configuration. If Environment 1 is set to use Database 1, then tasks running on Environment 1 will work on Database 1.
All you need to do is specify what tasks to run, at what time and in what environment.
I think the UI works better if we change the order of the input and ask for the environment first. You could set the fields in this order:
- Ask to select one environment from the list of existing environments
- Ask to select one background task from the list of background tasks existing in the selected environment
- Ask for the scheduling interval
The scheduling definition would look like this:
The summary would look like this:
where the two task_a are two different functions defined in two different environments.
With this framework I would be able to configure a task to run in the dev environment while I debug it.
When the task is ready for production I would merge dev to prod and the scheduler would still run the one from dev. Everything is ok because the one in dev and the one in prod are identical at this time.
Now I’m ready to check the scheduled task configuration and redefine the entry that runs the new task from running it in dev to running it in prod.
If dev and prod use different databases, I will need to change the scheduler configuration quickly, which is what I need to do today, but in a messier framework.
I’d like to suggest giving each row in the above display – the combination of environment + task (function) + schedule – a persistent ID, as well as notes. This will likely aid record-keeping, discussion, and technical support. It might also be a way to keep the combination under version control, if that is required.
2 Likes
I just found out that a task scheduled to run nightly has been running twice for the last few days:
I checked the scheduled task configuration and found out that I have one task scheduled to run on two environments.
I don’t know how this happened, but I don’t like it. This is just a cleanup happening twice, so not a big problem, but in other cases we could have dangerous side effects.
In other cases in other apps I have seen scheduled tasks that stopped working, perhaps for a similar unknown reason.
I don’t want to check the scheduled task configuration after every commit.
1 Like
The “Scheduled Tasks” page now allows to setup the scheduled tasks for all the environments in one page and merging two branches linked to environments with different scheduled task setups will not change the scheduled task setup.
YAY!!
I don’t know when the behavior has changed, I noticed it today, so I am adding [Done] to the subject today.
1 Like
