What does “all projects” mean in a scheduled task?
For aidd, I wanted it to mean whatever projects exist when the task starts. If I add an application tomorrow, the next scheduled audit should find it. I shouldn’t have to remember which recurring tasks need their project lists updated.
The first implementation made every project undeletable.
A task naming a particular project holds a reference to it. That lets aidd stop me from deleting a project that still has scheduled work pointed at it. The all-projects version initially behaved as though it held a named reference to everything it found, so even a project I wanted to remove was pinned by the recurring task.
I changed that. A fixed selection still holds its references. An all-projects task resolves its membership when the scheduler claims that occurrence, then records the exact paths it attempts. The following occurrence gets its own list.
That history matters when I come back to a failed run. The list of projects currently in aidd may have changed since it ran. I need to see what that particular occurrence tried to do. The scheduler also checks the stored selection again before dispatch, in case I edited the task while it was discovering projects.
There was a second bug in that discovery step. If it failed, the task’s next-run time stayed in the past. The scheduler immediately tried again, got the same error, and repeated. A failed claim now belongs to that task, with a delay before retrying, so it doesn’t stop the other due work or keep retrying at zero delay.
The release supports one-time and recurring work, with launch points for skills and audits as well as recipes and diary updates.
Both were covered before 2.140.0 went out. I still needed to watch a few real recurring occurrences and see what accumulated in the history.