Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repeatable Jobs - Ability to Upsert/Remove Job via Job ID Alone #2612

Closed
valeeum opened this issue Jun 18, 2024 · 3 comments
Closed

Repeatable Jobs - Ability to Upsert/Remove Job via Job ID Alone #2612

valeeum opened this issue Jun 18, 2024 · 3 comments

Comments

@valeeum
Copy link

valeeum commented Jun 18, 2024

Is your feature request related to a problem? Please describe.
I'm in the process of creating middleware for a microservices framework which allows services to run on a given schedule via BullMQ. The repeat options are provided in the service metadata as JSON configuration and the repeatable job is created when the service broker is initialized via the middleware. The issue I'm facing is that if the repeat job options are changed and service restarted, it would create two separate repeatable jobs.

Describe the solution you'd like

  1. Create a removeRepeatableByJobID method which would remove all instances of repeatable jobs by jobID (which i understand is not unique for repeatable jobs)
  2. Add optional upsert-like capability when adding repeatable jobs so that if an existing job is already defined (by jobId), it gets overwritten with the new repeat job options.

Describe alternatives you've considered
I understand that I can create a database table and store the repeatJobKey provided after calling the queue add() method and then use that value to call removeRepeatableByKey but it seems overkill for this purpose.

@valeeum valeeum changed the title Repeatable Jobs - Ability to Add/Update Job via Job ID Alone Repeatable Jobs - Ability to Upsert/Remove Job via Job ID Alone Jun 18, 2024
@doaortu
Copy link

doaortu commented Jul 6, 2024

For anyone stumbled in this issue,
while waiting the #2617 to merge,
I have a simple hack using existing redis connection to store the repeatJobKey :

const job = queue.add('name', data, {
  repeat: {
    // repeat opts,
  }
})
const ok = await conn.set("repeatable-job-id", job.repeatJobKey)

and when you want to remove the job, query the key and removeRepeatableByKey

const key = await conn.get("repeatable-job-id")
if(key) await queue.removeRepeatableByKey(key)
const ok = await conn.del("repeatable-job-id")

I don't know if this hack is truly safe, but I'm using it right now, and I haven't found a problem yet.

@valeeum
Copy link
Author

valeeum commented Jul 6, 2024

@doaortu

This is not safe because based on repeat options, you can have multiple jobs for the same job id.

github-actions bot pushed a commit that referenced this issue Jul 16, 2024
# [5.10.0](v5.9.0...v5.10.0) (2024-07-16)

### Features

* **repeatable:** new repeatables structure ([#2617](#2617)) ref [#2612](#2612) fixes [#2399](#2399) [#2596](#2596) ([8376a9a](8376a9a))
@manast
Copy link
Contributor

manast commented Nov 24, 2024

This has been now implemented using job schedulers: https://docs.bullmq.io/guide/job-schedulers

@manast manast closed this as completed Nov 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants