Available since v5.58.0
continueParentOnFailure option allows a parent job to start processing as soon as a child job fails, while the removeUnprocessedChildren method enables dynamic cleanup of unprocessed child jobs. Additionally, you can use the getFailedChildrenValues() method to determine whether the parent is processing due to a child failure or because all children completed successfully.
Key Features
continueParentOnFailure
Trigger parent processing on child failure
removeUnprocessedChildren
Clean up remaining unprocessed children
getFailedChildrenValues
Determine why parent is processing
continueParentOnFailure Option
When set totrue on a child job, the continueParentOnFailure option causes the parent job to begin processing immediately if that child fails. This contrasts with the default behavior, where the parent waits for all children to finish.
Key Behavior
- The parent moves to the active state as soon as a child with this option fails
- Other children may still be running or unprocessed
- Ideal for scenarios requiring immediate parent intervention
Basic Usage
removeUnprocessedChildren Method
This method, available on a job instance, removes all unprocessed child jobs (those in waiting or delayed states) from the queue. It’s particularly useful when paired withcontinueParentOnFailure to clean up remaining children after a failure.
Key Behavior
- Only affects children that haven’t started processing
- Active, completed, or failed children remain intact
- Call within the parent’s processor for dynamic cleanup
getFailedChildrenValues Method
ThegetFailedChildrenValues() method returns an object mapping the IDs of failed child jobs to their failure error messages. This allows the parent job to determine why it’s processing—whether due to a child failure or because all children completed successfully.
Return Value
- An object where keys are job IDs and values are error messages
- Example:
{ "job-id-1": "Upload failed" } - Empty object if no children failed
Complete Example
Here’s a comprehensive example combining all three features:Execution Flow
1
Child with continueParentOnFailure fails
child-job-1 encounters an error and moves to failed state.
2
Parent immediately becomes active
The parent job (root-job) is moved to the active state, even though child-job-2 and child-job-3 may still be waiting.
3
Parent processor runs
The parent worker picks up the job and executes the processor.
4
Check failed children
getFailedChildrenValues() returns the failed child information.5
Clean up unprocessed children
removeUnprocessedChildren() removes child-job-2 and child-job-3 from the queue.6
Handle failure path
Parent performs cleanup, notification, or other failure handling logic.
Use Cases
File Upload Workflow
File Upload Workflow
Consider a workflow where child jobs upload files to different servers. If one upload fails, the parent can react immediately:
Distributed Testing
Distributed Testing
Run tests in parallel and stop remaining tests if any critical test fails:
Multi-Region Deployment
Multi-Region Deployment
Deploy to multiple regions and rollback if any deployment fails:
Decision Logic Example
Here’s a pattern for handling both success and failure paths:Monitoring and Debugging
You can monitor the behavior using queue events:Best Practices
Always Check Failed Children
Use
getFailedChildrenValues() to distinguish between success and failure paths in your parent processor.Clean Up Resources
Call
removeUnprocessedChildren() to prevent unnecessary processing of remaining children.Handle Both Paths
Implement logic for both successful completion and failure-triggered processing.
Notify Stakeholders
Send appropriate notifications based on whether processing was triggered by success or failure.
