Skip to main content
In some situations, you may have a parent job and need to remove the relationship when one of its children fails. The removeDependencyOnFailure option allows the parent to complete without waiting for failed children.

How It Works

The removeDependencyOnFailure option makes sure that when a job fails, the dependency is removed from the parent, so the parent will complete without waiting for the failed children.
As soon as a child with this option fails, the parent job will be moved to a waiting state only if there are no more pending children.

Basic Usage

Behavior

When a child job with removeDependencyOnFailure: true fails:
  1. The dependency relationship is removed from the parent
  2. The failed child is no longer tracked in the parent’s dependencies
  3. The parent can complete without waiting for this child
  4. If this was the last pending child, the parent moves to waiting state
1

Child job fails

A child with removeDependencyOnFailure: true encounters an error and moves to failed state.
2

Dependency removed

BullMQ removes this child from the parent’s dependency list.
3

Check remaining dependencies

If there are still other pending children, the parent continues waiting.
4

Parent becomes active

Once all other children complete, the parent moves to waiting state and can be processed.

Example with Multiple Children

In this example:
  • If optional-enrichment or best-effort-analysis fails, they are removed from dependencies
  • The parent will process once required-validation completes
  • If required-validation fails, the parent will not process (default behavior)

Use Cases

Process data with optional enrichment steps that can fail without affecting the core workflow:
Send notifications that shouldn’t block the main workflow:
Track analytics without blocking the main business logic:

Difference from ignoreDependencyOnFailure

removeDependencyOnFailure is similar to ignoreDependencyOnFailure, but with key differences:

removeDependencyOnFailure

  • Completely removes the child from dependencies
  • Failed child is not tracked
  • Cannot retrieve failed child information later

ignoreDependencyOnFailure

  • Keeps the child in dependencies
  • Failed child is tracked as “ignored”
  • Can retrieve failed child information using getIgnoredChildrenFailures()

Monitoring Removed Dependencies

You can track when dependencies are removed:

Parent Processor Example

Handle the case where some children were removed:

Best Practices

Use for Optional Features

Apply to children that provide optional enhancements or features

Not for Critical Paths

Never use for children that are critical to the workflow

Log Removed Dependencies

Track when dependencies are removed for monitoring and debugging

Handle Missing Data

Parent should handle cases where optional children didn’t provide data
Use removeDependencyOnFailure carefully. The parent job will have no record of the failed child, making debugging more difficult. Consider using ignoreDependencyOnFailure if you need to track failed optional children.
For better observability, use ignoreDependencyOnFailure instead of removeDependencyOnFailure when you want to keep track of which optional children failed.

API Reference