Manuel Astudillo

I am not sure I understand the issue. You want to avoid that the next repetition is scheduled before the current one is being executed? If this is not super...

Maybe you can try to use job names to discriminate against different job types, and then instead of using repeatable jobs, just add a new job right before completing the...

I hope v5 resolves this issue for you (https://bullmq.io/news/231221/bullmqv5-release/), let me know.

We are putting our efforts into this project: https://github.com/taskforcesh/bullmq-proxy It would be more valuable to write a "golang" thin interface for the proxy. Here a blogpost I wrote about it:...

@elee1766 keep me posted and I will try to help you as much as I can.

Ok, I see that ```runStalledJobsCheck()``` is not executed in the manual case, we need to fix this.

In this case I think that what you would like to do is to set-up retries on every individual "task". So if for example task4 fails, you retry according to...

I got this suggestion by ChatGTP: Yes, you can achieve the behavior you're describing using cron expressions in BullMQ, or any other job scheduling system that supports cron-like scheduling. Cron...

With the new API I hope this issue can be easily accomplished, either using cron expressions or a custom repeat strategy: https://docs.bullmq.io/guide/job-schedulers

Not sure what the issue is here. So, a job that is not keeping the event loop busy will not have any issues, you should not change the lockDuration setting...