Skip to main content

Overview

BullMQ provides a retry 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()

The retry 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

From src/classes/job.ts:1475:

Retry Options

The retry 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

The attemptsMade counter tracks how many times a job has been processed. Resetting it allows the job to use its full retry allowance again.
From src/classes/job.ts:115:

Reset Attempts Started

The attemptsStarted counter tracks how many times a job has been moved to the active state:
From src/classes/job.ts:107:

What Happens When You Retry

When a job is retried, the following occurs:
  1. Job is moved to waiting queue: The job is removed from the completed/failed set and added back to the waiting queue
  2. Properties are cleared: The following job properties are reset to null:
    • failedReason
    • finishedOn
    • processedOn
    • returnvalue
  3. Events are emitted: A waiting event is emitted when the job is successfully moved
  4. Parent dependencies restored: If the job is a child in a flow, its dependency relationship with the parent is restored
If you retry a job without resetting attemptsMade, and the job has already exhausted its retry attempts, it will fail immediately when processed again.

Error Handling

The retry method can fail in the following cases:

Automatic Retries vs Manual Retries

Automatic Retries

Configured via attempts option
Jobs automatically retry when they fail, up to the specified number of attempts.

Manual Retries

Using job.retry() method
Manually retry a completed or failed job at any time, with full control over reset options.

Common Use Cases

When an external API or service is temporarily down:
After deploying a bug fix:
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

From src/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