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

Promoting a recurring job does not schedule the next job #247

Open
jasonkim opened this issue Jul 30, 2020 · 9 comments · May be fixed by #2944
Open

Promoting a recurring job does not schedule the next job #247

jasonkim opened this issue Jul 30, 2020 · 9 comments · May be fixed by #2944
Assignees

Comments

@jasonkim
Copy link

I'm not sure if this is the expected behavior.
If I were to promote a recurring job, it should run it and then ideally queue the next job.

@manast
Copy link
Contributor

manast commented Jul 31, 2020

It should work, since a recurring job is waiting as a delayed job, can you provide a test where this does not hold?

@jasonkim
Copy link
Author

jasonkim commented Aug 3, 2020

Finally got around to create a simple case.

import ioredis from 'ioredis'
import bullmq from 'bullmq'
function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}
async function test() {
  const { Queue, QueueScheduler, Worker, Job } = bullmq
  const connection = new ioredis()

  // bull-board
  const { setQueues } = bullboard

  const testq = new Queue('test', {connection})
  testq.add('recurring', {}, { repeat: { cron: '* * * * *' } })
  setQueues([testq])
  new QueueScheduler('test')

  new Worker('test', async job => {
    console.log(Date())
    console.log(job.id)
  })

  await sleep(90000)
  console.log(await testq.getDelayedCount())
  const jobs = await testq.getDelayed()
  const job = jobs[0]
  // console.log(job)
  job.promote()
  console.log("Promoted")
  await sleep(1000)
  console.log(await testq.getDelayedCount())

}
test()

I'm using a bull-board, but you can comment that out as that is not very important.
It should print the datetime and jobid every time the worker runs, but after promotion, it stops.
I've put in sleep function, but that's not very important and just shows that the recurring job works.

@Khauri
Copy link

Khauri commented Aug 4, 2020

Also noticed this issue. Promoting the job would run the process function, but the job would not be rescheduled afterwards.
I had to work around this by essentially duplicating the data of the recurring job into a new job and adding that to the queue.

@manast
Copy link
Contributor

manast commented Aug 8, 2020

I have reproduced this issue and know exactly why it happens, but I need some time to fix it.

@Khauri
Copy link

Khauri commented Aug 8, 2020

Thanks! In the meantime I've just done this and it works for my purposes:

if(/^repeat:/.test(job.id)) {
  await queue.add(job.name, job.data);
} else {
  await job.promote();
}

But I do have a small question. When promoting a repeating job, say one that runs hourly with the next execution time being 10am, is the intended behavior to keep the scheduled time for the job as its next execution time (still 10am), or would it be to schedule it for the next hour afterwards (11am?).

@manast
Copy link
Contributor

manast commented Aug 10, 2020

@Khauri it will be scheduled to the next run.

@janfietz
Copy link

I had the same issue. I promoted a repeating job with bull board. It disappeared from the delayed list and never came back.

@roggervalf
Copy link
Collaborator

Yeah, it's related to this line https://github.com/taskforcesh/bullmq/blob/master/src/commands/promote-5.lua#L20, where job is deleted from delayed list

@manast
Copy link
Contributor

manast commented Nov 26, 2024

@fgozdz I think this issue has been resolved some time ago, specially with the new job scheduler, could you please verify that it works now with a new test case so that we can close this issue?

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

Successfully merging a pull request may close this issue.

6 participants