Failure handling
Choose how a failed step affects the rest of the flow.
Failure transitions route execution. They do not repair answers, roll back side effects, or retry automatically.
Choose the behavior
| Method | Behavior |
|---|---|
OnFailureStop() | End as failed; the default. |
OnFailureContinue("step-id") | Continue at the named step. |
OnFailureGoTo("step-id") | Route to a named fallback. |
The current runner resolves the named failure target for both continuation and fallback. Neither adds a retry or a different input payload.
Stop when output is required
The summary example stops when summarization fails:
A reviewer expecting a summary should not accidentally receive the original text after failure.
Design the recovery input
A failure target receives the input that entered the failed step. If recovery needs error details or a combined payload, arrange that explicitly in application code.
The failed step remains in the result even if recovery completes. Overall completion does not mean every step succeeded.
Keep retries bounded
Validation checks target existence but does not reject cycles. Routing a failure back to itself is not a bounded retry policy.
Keep flows acyclic unless the application implements a termination strategy. Retrying side effects also requires application-level idempotency.
Continue with Patterns.