I was reviewing another issue and then saw that we actually read always the cached option entry for the scheduled tasks timetable by the looks. This is executed in https://github.com/matomo-org/matomo/blob/4.4.1/core/Scheduler/Scheduler.php#L105-L115
Because it is normal to have 2 or many more archivers running in parallel it's not uncommon that multiple archivers might execute the task runner at the same time. They would all fetch the timetable (the entries of what scheduled tasks to execute when) and they would all have a different version of it and work on this version constantly. However, because it can take a long time (from seconds up to hours) to execute all tasks, there's a high risk that some tasks may be executed multiple times if we don't always read the timetable from the database. It will cause quite a few additional queries but should reduce some concurrency issues.
Currently, there was already code to always read the DB value again. However,
Option::get would always first return a cached result from memory and not fetch the DB again.
Basically this is how it currently looks like:
job 1: load tasks, returns [a,b,c,d] job 1: work task a job 2: load tasks, returns [b,c,d] job 1: work task b job 2: work task b job 1: work task c job 2: work task c ...
The task runner logic is still far from being thread safe but this should improve it quite a bit.
Consequence of all this is a lot of added load as several tasks may be executed multiple times, potentially some scheduled reports or custom alerts may be sent multiple times (I remember seeing such reports), etc.
Please include a description of this change and which issue it fixes. If no issue exists yet please include context and what problem it solves.