Prevent a scheduled job to run while its previous execution is still running

[marcolubian]

I'm using the upsertJobScheduler feature to setup a job that runs each 1 minute:

await queue.upsertJobScheduler('myJob', {
  every: 60000,
});

• Let's say that the job is executed at 15:30 and that it requires 30 seconds, it's then expected to be executed at 15:31, and it actually will, it's ok.
• But let's now say that the job is executed at 15:30 and that it requires 1 minute and 30 seconds, how can I prevent it from being executed at 15:31?

In other words, is it possible to allow a unique execution of the same (scheduled) job at a time?

I know that I could act on the Worker side to do nothing if the job is still running, but how can I avoid at all the queue to generate the new job instance? I've seen that there is a limiter option, I've tried setting it to something like this:

limiter: {
    max: 1,
    duration: 24 * 60 * 60 * 1000, // 24 hours
},

but it seems to not work or maybe I'm not interpreting it in the right way, or maybe I'm setting it in the wrong place.

Is there a way to achieve what I need?

[manast]

This is not currently possible but we have a new feature in the pipe called "sequential jobs" that would work kind-of, in the sense that jobs would never overlap but it will not really skip the missed slots (unless its duration more than double of the every setting). For example say you iteration 1 at 15:30:00, it ends at 15:31:30, then the second iteration would start immediately at 15:31:30 and the next iteration would be at 15:32 at the earliest or after the second iteration completed.

[marcolubian]

Ok, actually that was the second question in fact :-). To me it seems reasonable to act in the way you wrote: if the next slot is skipped, it's correct that after the iteration the job is immediately executed. Can you tell me for when it is expected the release of this new feature? It would really help our implementation.

[manast]

Well I am not sure about the release date, but this is most likely going to be a Pro feature, as it is quite involved to implement.