Worker can get caught in infinite loop when redis connection is closed unexpectedly

[airhorns]

Because of https://github.com/taskforcesh/bullmq/blob/master/src/classes/worker.ts#L192-L195 , I am seeing workers get caught in an infinite loop of trying to get the next job only to error again trying to get the next job.

The loop is this:

• Redis connection is closed somehow (I assume this is my code doing this but don't have a smoking gun yet)
• worker is not closed explicitly, this.closing inside the worker is undefined
• worker run loop calls getNextJob asynchronously, which calls waitForJob, which calls BRPOPLPUSH
• Redis client synchronously throws, which interrupts execution of waitForJob, and is caught in getNextJob, and swallowed
• getNextJob call wins the Promise.race in worker run loop
• getNextJob call returns nothing, so worker doesn't work the job
• worker run loop repeats the process

I am not sure why that error is being swallowed, or why the Connection is closed. message is special. If I had to guess, special care has to be taken to handle connection closes that we expect on the blocking calls like that. In this case though, the worker has not been explicitly closed, and it's being asked to use a closed redis connection, which I think should be an error that at least gets emitted and maybe takes down the process if unhandled.

Happy to do up a PR if someone can tell me what the semantics should be!

[airhorns]

Also, I think this is actually the root cause of #359, not pausing! The event loop starvation happens where my timeouts for a test or what have you never fire because of this async-but-infinite loop that has higher priority in the node tick order I think.

[manast]

I am working on a fix for this. This issue exists in bull v3 and I expect to have a fix by tomorrow.

[github-actions]

🎉 This issue has been resolved in version 1.14.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[airhorns]

Thanks @manast !