-
Notifications
You must be signed in to change notification settings - Fork 391
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 are duplicating due to "count" option field #453
Comments
Could you provide a test code that reproduces the issue?, because it should not work as you described it. Using the same cron does not yield duplicates independently if it has already executed some iterations or not. |
Lack of more content is really sad. I am running into this issue, but in a different way where I actually update the |
@JefferyHus can you provide some code that reproduces the issue? |
// this is my job
queue
.add(name, {...}, {
repeat: {
pattern: '* * * * *',
},
})
.catch((e) =>
logger(LogLevelsEnum.ERROR, `CRON JOB Error: ${e.message}`),
);
// if go and change the pattern, bullmq will duplicate it.
queue
.add(name, {...}, {
repeat: {
pattern: '*/3 * * * *',
},
})
.catch((e) =>
logger(LogLevelsEnum.ERROR, `CRON JOB Error: ${e.message}`),
);
// I understand that it was mentioned in the docs explicitly
// but if there was an easy way to decide if we want to keep it or replace the existing one |
A job with a different pattern is considered a different job. |
I did mention that above. It was a bit of overwork to find the job and replace it, and my request was to just if there will be in the future any consideration for this or not |
We have a PR open that addresses this issue: #1824 |
The BullMQ documentation says:
So I tested if BullMQ can handle same repeatable jobs with same repeat options to not duplicated even if it is called several times.
I added the below line of code to my server.
It's simple cronjob definition with constant name. I confirmed that bullMQ is "smart enough" to find out that the job is duplicated, if I call above line of code many times without any delay in time. So far so good.
So I waited to the cronjob is executed once, and then called above line of code again. This time, bull added the duplicated job to the queue, even it's already existing.
I think the problem is that, after initial execution (or nth) the job that added to queue by BullMQ has the increased "count" field in repeat option, so BullMQ considers two jobs are different job even if the source of code that added them to queue is exactly same.
In my opinion, In this case, there's no difference of repeat option between two jobs, thus it shouldn't be duplicated.
If this is expected behavior, the documentation should have correct context of "How smart the BullMQ is", because current documentation is somewhat confusing.
The text was updated successfully, but these errors were encountered: