Overview
BullMQ provides aretry method that allows you to programmatically retry jobs that have already completed or failed. This is different from the automatic retry mechanism (configured via the attempts option) - the retry method lets you manually move a job back to the waiting queue at any time.
Only jobs in the
completed or failed state can be retried. Active, waiting, or delayed jobs cannot be retried.When to Use Job.retry()
Theretry method is useful in scenarios such as:
- Manual intervention: When a job failed due to a temporary external issue that has been resolved
- Re-processing completed jobs: When you need to run a completed job again with the same data
- Workflow recovery: When recovering from system failures or bugs that caused jobs to fail incorrectly
Basic Usage
src/classes/job.ts:1475:
Retry Options
Theretry method accepts options to reset attempt counters, allowing the retried job to behave as if it’s being processed for the first time.
Reset Attempts Made
TheattemptsMade counter tracks how many times a job has been processed. Resetting it allows the job to use its full retry allowance again.
src/classes/job.ts:115:
Reset Attempts Started
TheattemptsStarted counter tracks how many times a job has been moved to the active state:
src/classes/job.ts:107:
What Happens When You Retry
When a job is retried, the following occurs:- Job is moved to waiting queue: The job is removed from the completed/failed set and added back to the waiting queue
- Properties are cleared: The following job properties are reset to
null:failedReasonfinishedOnprocessedOnreturnvalue
- Events are emitted: A
waitingevent is emitted when the job is successfully moved - Parent dependencies restored: If the job is a child in a flow, its dependency relationship with the parent is restored
Error Handling
Theretry method can fail in the following cases:
| Error Code | Description |
|---|---|
-1 | Job does not exist |
-3 | Job was not found in the expected state |
Automatic Retries vs Manual Retries
Automatic Retries
Configured via Jobs automatically retry when they fail, up to the specified number of attempts.
attempts optionManual Retries
Using Manually retry a completed or failed job at any time, with full control over reset options.
job.retry() methodCommon Use Cases
Retry After External Service Recovery
Retry After External Service Recovery
When an external API or service is temporarily down:
Re-process with Updated Code
Re-process with Updated Code
After deploying a bug fix:
Rerun Completed Jobs
Rerun Completed Jobs
Process a completed job again (e.g., regenerate report):
Retry with Flows
When retrying a child job in a flow, the parent-child relationship is restored:Job Attempt Counters
Fromsrc/classes/job.ts:107-116:
Read More
Retry API Reference
View the complete Retry API documentation
Automatic Retries
Learn about automatic retry configuration with backoff strategies
Stop Retrying Jobs
How to prevent further retries using UnrecoverableError
Job States
Understanding job states and lifecycle
