Error Propagation
How child workflow failures surface in the parent — sync mode error port, async mode silent failure, and compensation patterns.
Sync Mode — Error Port
In synchronous mode, if the child workflow terminates in a Failed state, the SubWorkflow node fires its error port in the parent. The error output contains details about what went wrong:
{
"childExecutionId": "exec-101",
"failedAt": "2026-05-25T10:05:00Z",
"failureReason": "Node 'sendNotification' threw HttpRequestException",
"failedNodeId": "sendNotification",
"errorMessage": "Connection refused"
}
Access in the parent's error handler:
$output.runApproval.failureReason // "Node 'sendNotification' threw HttpRequestException"
$output.runApproval.childExecutionId // "exec-101" — for audit lookup
Sync Mode — Error Handling Pattern
┌─────────────────┐
│ SubWorkflow │
│ (runApproval) │
└────────┬────────┘
│ ┌─────────────────────┐
├─ main ──────▶ Continue parent... │
│ └─────────────────────┘
│ ┌─────────────────────┐
└─ error ─────▶ LogChildFailure │
│ + SendAlertEmail │
└─────────────────────┘
Async Mode — Silent Failure
In async mode, the parent does not observe child failures. The child's failure is recorded in the child execution's own audit log but does not affect the parent at all. Strategies for handling async failures:
- Design the child to always handle its own errors (never leave a node without an error edge)
- Use a separate monitoring workflow that polls child execution statuses and alerts on failures
- Store the
childExecutionIdin a database entity, then have a background job check status
Cancelled Parent = Cancelled Child
If the parent execution is cancelled while a child is running (in sync mode):
- The parent's cancellation token fires
- The engine sends a cancellation signal to the child execution
- The child transitions to
Cancelled - The parent also transitions to
Cancelled
In async mode, cancelling the parent does not cancel already-launched child executions. They run to completion independently.