Feature request: Including failed jobs in QueueEvents "failed"

[hardcodet]

I'm migrating from Bull to BullMQ and was wondering on how to handle failed jobs without establishing a worker for every single job. On Bull, I just picked them off the Queue, and the new QueueEvents class seems to be the logical successor. However, it only gives me the job's ID rather than the Job itself, which is just a random ID.

Given that Bull could do it, wouldn't it make sense to submit the Job as well? In the past, we would have logged the whole job, which would have allowed us to diagnose the context of about what happened. Should (can?) we now retrieve the job in a subsequent call? This feels problematic as well given that things already went sideways... :)

[manast]

If you listen to the failed event from a worker instance you will also get the job instance that failed.

[hardcodet]

Done, thanks for the quick turnaround!

FYI: The documentation on https://docs.bullmq.io/guide/workers indicates that the second parameter of the worker's failed event was a failedReason string, but it's the actual error (which is great).

[github-actions]

🎉 This issue has been resolved in version 1.68.2 🎉

The release is available on:

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

Your semantic-release bot 📦🚀