Possibility to add "backoff" to the task interval?

[gary-menzel]

In some situations you may want a job to usually run (say) every minute.

But, assuming your tasks have persistent state, there may be nothing to run (e.g. a workflow might have a scheduleAt date and not be returned from a database call until that date had passed). In such a situation you may then want to try again five minutes later, then twenty... etc. If your job detects there is work to do, it would then reset back to the original interval.

I noted somewhere in the issues that it had been suggested to use setTimeout instead of setInterval. If this were done, then it may be fairly simple to implement a "backoff".

I don't have a lot of spare time but could look into how it might be done. The biggest issue, as I see it, is that the the actual scheduler and the job really don't have a communication path (not a bad thing - but makes this more difficult to implement). There would need to be some way for the job to tell the scheduler to backoff as well as reset (function calls to the right part of the scheduler). Then the "schedule" attached would only need to provide a "backoff" array (or the seconds could be an array or number) giving the successive intervals for each of the backoffs (and if the final one was reached just stay at that interval).

Does anyone using Toad Scheduler have a similar need and would it be something that people are interested in?

Or has anyone already implemented this?

[kibertoad]

I would appreciate a PR for this!

[gary-menzel]

I'll see what I can do. I have a lot on my plate at the moment and will need to set up a fork for this. At this point in time, I don't yet have the need for it but it seems to make sense instead of running tight timing on loop that may often not have anything to do. I would also look up the recommended change from setInterval to setTimeout and apply that as I think that would make the backoff approach easier.

[gary-menzel]

Both changes should be possible and also better managed with the addition of a runTask to the SimpleIntervalJob. At present, the execute function returns nothing and the SimpleIntervalJob ignores it. So my proposal is to use the return value from the execute function to provide a new timer value (either in ms or as a SimpleIntervalSchedule), detect that, and set the new timeout based on that value. This means the backoff strategy is with the actual job handler and not with the Scheduler itself. This approach should be fully backwards compatible.

I don't think this approach is viable (or relevant) for the LongIntervalJob. A long running job probably doesn't need a backoff strategy.