I’ll note that the @PanIndustrial TimerTool can help this a bit by filing multiple executions under one proxy timer call. Whenever the library is invoked it pulls all set timers with targets less than the current timestamp and attempts to execute them with noop self awaits if you specify that(which in some instances execute mostly in sync but I’m not sure how a Bob situation affects that…ie I don’t know if motoko is doing some virtual scheduling before handing back to the replica scheduler or not…I think there is virtual scheduling based on some issues I’ve seen in GitHub) between such that if one fails it isn’t removed from the queue. Or you can force only sync items and specify an upper limit on tasks to handle during one round*.
The down side is you have to mange your own recurrence. This is both good and bad. Good so that if you are 23 minutes late on a one minute recurring timer you don’t have 23 others scheduled*. Bad in that you have to mange it, but the code to do so is trivial.
- My understanding of the way motoko does recurring times is that like 10 are scheduled ino a priority queue that is picked up on a callback to schedule the next one as @ggreif explains here Motoko - Timers - Specific Behavior - #3 by ggreif. I’m assuming that stale queue items that have a more fresh brother invocation are dropped, but I’d love to get confirmation on that given the whole BOB situation.
Using native motoko timers, if you schedule 10 different tasks with 10 timers at 10 different times during a delay cycle I’d expect that currently possibly only the first one will get scheduled(especially if you have other ingress messages) and you might have to wait for 23 minutes to see the next one(or longer if you have a lot of ingress as timers can get de-prioritized.)
It would be really, really nice to have a detailed flow diagram of the scheduler that includes an sdk layer.
- I need to check out the new finally as I may be able to now recover and properly recover if finally is run even if you hit the cycle limit.