You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
My problem is similar to the one which inspired until_executing, but a bit different. We have a long-running job that gets triggered by updates from a number of different sources. This job requests data at the beginning of its run and there's a danger that the data can become stale by the time it finishes. Therefore, we need this job to run once after the final trigger. However, once it starts running, we don't want to interrupt it, and we also don't want to run multiple at the same time (since it's big and expensive).
So if we get an initial trigger, we want the job to start running, and then if we get another trigger, we want to enqueue another job to run after the first finishes, but if we get another trigger after that, we want to ignore it (since we can be sure that the enqueued job will have access to all the data it needs by the time it starts running).
Describe the solution you'd like
I'd love something like lock: :max_one_executing_and_one_enqueued, where we have one lock for the queue and one lock for execution. This means if we get a flood of requests, one will start running, one will wait to start until after it finishes, and subsequent requests will be ignored.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
My problem is similar to the one which inspired
until_executing
, but a bit different. We have a long-running job that gets triggered by updates from a number of different sources. This job requests data at the beginning of its run and there's a danger that the data can become stale by the time it finishes. Therefore, we need this job to run once after the final trigger. However, once it starts running, we don't want to interrupt it, and we also don't want to run multiple at the same time (since it's big and expensive).So if we get an initial trigger, we want the job to start running, and then if we get another trigger, we want to enqueue another job to run after the first finishes, but if we get another trigger after that, we want to ignore it (since we can be sure that the enqueued job will have access to all the data it needs by the time it starts running).
Describe the solution you'd like
I'd love something like
lock: :max_one_executing_and_one_enqueued
, where we have one lock for the queue and one lock for execution. This means if we get a flood of requests, one will start running, one will wait to start until after it finishes, and subsequent requests will be ignored.The text was updated successfully, but these errors were encountered: