Include retry exhaustion in the Job API for job status

[JonathanSun]

Is your feature request related to a problem? Please describe. We would like to show the status of a job in our UI when failed/completed, without being sensitive to the number of retries. It's difficult to distinguish a failed job (that is going to retry) vs. a failed job that has exhausted its retries using the Job API. It seems like the status of retries being exhausted is only available via QueueEvents.

Describe the solution you'd like A field on Job like retriesLeft or retriesExhausted that can be polled to see if the job is going to retry on failure.

Describe alternatives you've considered Using the QueueEvents API to return the retry status to the UI is more complicated, and does not mix well with polling for job status.

[manast]

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.

[DrShortStack]

Forgive me if that's the intention but that's not how your docs describe it. In 'Retrying failing jobs' it recommends that we 'throw' Error objects to get a retry: https://docs.bullmq.io/guide/retrying-failing-jobs

In there is states that 'When a processor throws an exception, the worker will catch it and move the job to the failed set.'

When I do that it hits the failed event listener on my worker and then if it has a retry it will try again else it will stay there until the queue is cleaned.

What would be the recommended approach here?

[roggervalf]

hey folks, job exposes https://api.docs.bullmq.io/classes/v5.Job.html#attemptsMade attribute that can be compared with your attempts option. Or you can call job.getStatus method as that one will also take in count cases where you move your job directly to failed with an Unrecoverable error.