Manuel Astudillo

> * either the audio service knows beforehand all of the possible result queues and registers them at startup (this is not possible since consumer services are dynamic and the...

That's why I am suggesting to have several result queues instead. But as the queues may be dynamic, the workers will need to instantiate a queue every time they want...

A job that is in the failed status has actually exhausted all its retries, otherwise it would be in the delayed status waiting for the next retry.

Most likely produced by Promise.race() https://github.com/nodejs/node/issues/24321

The version of BullMQ that you are using is a bit old, so the question is if this can be reproduced with the latest version, as the way we handle...

We will need some test code that reproduces the issue, even though the behaviour would not happen all the time, we need to be able to reproduce it somehow to...

Thanks for the repo. Actually this behaviour could be resolved by this PR: https://github.com/taskforcesh/bullmq/pull/2309 After a positive review we will merge it.

If you can check if the previous job for a given repeatable job has not done its work yet, then you could just return from that job doing nothing. I...

I was thinking more along the lines of checking your service if the previous job is being still processed or not, as if you have some database field that you...

If we were going to make a change like that in BullMQ I would prefer to have a different repeat setting that creates the next repetition at the current job's...