clean all delayed jobs can finish on inconsistent state

[Zikoel]

Hi,

Maybe I'm wrong but I notice that if you clean all delayed jobs this doesn't remove repeatable jobs. This is not an expected behavior because if you ask to bull for repeatable jobs it returns your jobs but that repeatable will never run again because the delayed counterparts are deleted. I think this is an inconsistent state for bull,
I'm not sure here what is the best things to to, maybe one of these:

• Create a new tab for repeatable jobs and remove from the delayed the repeatable counterpart, threat all repeatable at the same manner
• When delete delayed job if there is a repeatable counterpart remove that too (maybe notify the user that some delayed job are chained to a repeatable job)

This make sense for you or just I don't understand well what happen inside bull ?

[felixmosh]

I'm not sure regarding that, but sounds like bull should handle this... This lib calls bulls queue.clean, if it doesn't remove all the parts it is bull's bug.

Wdyt?

[felixmosh]

Ping?

[mdgozza]

Hi @felixmosh

I ran into this issue as well. It appears the only proper way to remove repeatable jobs is to use the removeRepeatable methods
https://github.com/OptimalBits/bull/blob/master/REFERENCE.md#queueremoverepeatable

I simply wrote something like this to fix my inconsistent state:

// remove all repeatable jobs
  const repeatableJobs = await queue.jobQueue.getRepeatableJobs();
  await Promise.all(
    repeatableJobs.map((j) => queue.jobQueue.removeRepeatableByKey(j.key))
  );

Also, on a side note: I think distinguishing delayed from repeating tasks would be kinda neat.

In the meantime I enabled readOnlyMode for that queue until the delete methods can be trusted 👌

[felixmosh]

Thank you for the explanation, I'll review a possible solution soon 🙏🏼

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ThomasKoscheck]

Hey,
are there any updates on this?
This bug still exists

[felixmosh]

Hi @ThomasKoscheck this bug totally slip my eyes, can you explain how can I reproduce it?

[ThomasKoscheck]

Sure, the reproduction is quite easy

1. Create a MQ

const myQueue = new Queue("myQueue", {connection: redisOptions});

2. Create a repeatable job in the queue

await BullMq.addRepeatableJobToQueue(
        'myQueue',
        'jobname',
        data,
       1000 * 60, // just as example
        'myId'
    );

3. Delete from bullboard

Navigate to bullboard > myQueue > Delayed and delete the job with the icon

The job disappears from bullboard and seems to be deleted

But if you query bullmq with

const queue = BullMq.getQueueMq("myQueue");
const repeatableJobs = await queue.getRepeatableJobs()

the deleted job is still existing, but won't be executed in future (to me, it looks like the job lost the repeating property)

I am using @bull-board/fastify: 5.8.1 and bullmq: 4.9.0

[felixmosh]

Thank you, I'll check if that is an issue of the lib or the board.
To me it sounds like when ever we call to job.delete, it must handle all of its states...

[Cr0s4k]

any update? this behavior is also a bit strange for me