bullmq icon indicating copy to clipboard operation
bullmq copied to clipboard

Allow deduplicated jobs to queue when job is already running

Open nwalters512 opened this issue 9 months ago • 5 comments

Is your feature request related to a problem? Please describe.

I want to run a certain task in response to some user activity. However, it's an expensive task, and users could potentially do the triggering activity many times in rapid succession. I can achieve this pretty well with deduplication (https://docs.bullmq.io/guide/jobs/deduplication).

However, I want to be absolutely sure that I'll always run the task after the latest user action such that I never fail to process the latest state. Based on the docs, this doesn't seem to be the behavior:

While this job is not moved to completed or failed state, next jobs added with same deduplication id will be ignored and a deduplicated event will be triggered by our QueueEvent class.

I interpret this to mean that while my job is running, if I try to enqueue another job with the same deduplication ID, it will not be queued and will never run after the current one is done executing. This means that sometimes, I'll fail to process the latest data from the user.

Describe the solution you'd like

Back when debouncing (which ultimately became deduplication) was first proposed in https://github.com/OptimalBits/bull/issues/1034, what I'm describing was actually spelled out explicitly as a requirement for this new functionality: https://github.com/OptimalBits/bull/issues/1034#issuecomment-734181580. However, as far as I can tell, it was just never implemented (or if it was, it's not documented). For context, the functionality was implemented here: https://github.com/taskforcesh/bullmq/pull/2796

Describe alternatives you've considered

I'm not sure if there is one. Maybe it's already possible with the right set of flags and options? Or maybe things already work how they were originally specced to and the docs just don't reflect that? Any guidance would be appreciated.

nwalters512 avatar Mar 17 '25 17:03 nwalters512

Amazing timing. We ran into the need for this today and were surprised there was no support.

mattmcmanus avatar Mar 17 '25 18:03 mattmcmanus

We do too, that would be such a nice improvement

billouboq avatar Mar 17 '25 23:03 billouboq

big +1

Edit: removed related requests will create separate issues

mt-bt avatar Mar 17 '25 23:03 mt-bt

I'd encourage you to create other issues with your requests so we can keep the conversation narrowly focused on this one.

nwalters512 avatar Mar 18 '25 00:03 nwalters512

This would be something like instead of adding a standard job you would use a delayed job, the difference would be that instead of ignoring the next job that you add you would replace the previous delayed job and reset the delayed time. So if no new job is added before the delayed expires, the delayed job is effectively processed.

manast avatar Apr 24 '25 17:04 manast

available since v5.56.0

roggervalf avatar Jun 22 '25 18:06 roggervalf

I'm not sure this entirely resolves this issue.

Correct me if I'm wrong, but it requires me to delay all jobs by a certain time period (TTL)?

What if I don't want to delay them?

I'd still want the job to be queued and executed as soon possible. However, if there's a incomplete job (that hasn't been started to be processed yet), I'd like to add it to the queue. (Even though that'd be a duplicate and could cause the same job to be processed twice in series/parallel.)

Is that currently possible in BullMQ?

jtomaszewski avatar Sep 03 '25 11:09 jtomaszewski

@jtomaszewski not sure I understand your case completely, but it seems like what you want is just the basic case of deduplication based on jobIds? i.e. there can only be one job with a given id in the queue, if you add another job with the same id the second job will be ignored.

manast avatar Sep 04 '25 08:09 manast

More info here: https://docs.bullmq.io/guide/jobs/job-ids

manast avatar Sep 04 '25 08:09 manast

Hey @manast . I need:

  • no arbitrary delays (run a job as soon as possible)
  • never run the same job twice in parallel (instead, either skip processing it if there's already one in waiting state, OR, reprocess AFTER the currently active one finishes)
  • ensure at least one job starts (and completes) AFTER a job schedule is requested.

Job IDs and current deduplication options don't help. https://github.com/taskforcesh/bullmq/issues/3427 would.

jtomaszewski avatar Sep 04 '25 08:09 jtomaszewski

@jtomaszewski nor will work to enqueue a job if the previous one is in active status as any other worker will be able to start processing it before the previous one has completed. Which actual use case requires this functionality?

manast avatar Sep 04 '25 10:09 manast