Context
The orchestrator supports graceful failure: when a task fails, its dependents are blocked while independent tasks continue. This is documented in the orchestrator's docstring as a key design decision, but no example demonstrates this behavior.
Proposed example: 09-error-handling.ts
A pipeline where one task intentionally fails, showing how the framework handles it:
- 4 tasks in two branches:
A → B and C → D
- Task A deliberately fails (e.g., calls a nonexistent API or throws an error)
- Task B is blocked (depends on A)
- Tasks C and D run and complete successfully
- Final result shows mixed statuses:
completed, failed, blocked
- Demonstrates
TeamRunResult.success === false with partial results still usable
APIs to showcase
TaskStatus: 'failed' and 'blocked' states- Failure cascade through dependency graph
- Partial success in
TeamRunResult.agentResults
- Error events in
onProgress callback
Acceptance criteria
Context
The orchestrator supports graceful failure: when a task fails, its dependents are blocked while independent tasks continue. This is documented in the orchestrator's docstring as a key design decision, but no example demonstrates this behavior.
Proposed example:
09-error-handling.tsA pipeline where one task intentionally fails, showing how the framework handles it:
A → BandC → Dcompleted,failed,blockedTeamRunResult.success === falsewith partial results still usableAPIs to showcase
TaskStatus:'failed'and'blocked'statesTeamRunResult.agentResultsonProgresscallbackAcceptance criteria
examples/09-error-handling.tsnpx tsx examples/09-error-handling.tsruns successfully (exits 0 despite partial failure)npm run lintpasses