Manuel Astudillo

Here you can get some information to start with: https://docs.bullmq.io/guide/troubleshooting#missing-locks

Most likely your job stalled, some other worker managed to process it and then it failed because the first worker managed to complete the job (as it was not really...

If you do not need a lot of concurrency you can try sandboxed processors (https://docs.bullmq.io/guide/workers/sandboxed-processors), the best would be to make sure your process function does not block the NodeJS...

Unfortunately there is not a lot for us to go for with this information... are there jobs in the wait list, or delayed, are all the expected workers actually online?

> The jobs are not delayed ones, so they should be in the wait list. > > > Could you please verify that this is the case, as "should" here...

> > You can use Taskforce.sh or any other frontend to check which workers are online for a given queue. > > Sadly I use AWS MemoryDB and it is...

> I can confirm they are in the waiting status And the workers are idling and online?

It could also be that MemoryDB does not implement this command: https://redis.io/docs/latest/commands/client-setname/ but I could not find in the documentation of MemoryDB that this is not the case.

This is a highly requested feature actually and BullMQ does not yet provide a way to do this natively, I would be happy to work on a feature like this...

yeah, I know bluebird's cancellation mechanism and also I am familiar with the early cancellation specs for promises. The good thing was that you could cancel the promise easily and...