Relationships
#3202 A garbled nested run record crashes a parent resume with a YAML stack trace
Opened by zack · 10/8/2026· Shipped 10/9/2026
Problem
Resuming a parent run whose nested workflow step waits on a child run fails with a raw YAML parse error and stack trace when the child's run record on disk cannot be parsed (for example a hand-edited or truncated run file).
Found while reviewing swamp-club#3110. It predates that change and is not about signal waits.
Where
The refusal path that checks whether nested runs have finished reads the child run record and lets the parse error escape: resolveResumableRun in src/domain/workflows/suspended_run_resolver.ts calls assertNestedWaitsSettled, which goes through NestedRunLink.resolveChild in src/domain/workflows/nested_run_link.ts and the run repository's findById.
Expected
A user-facing error that names the nested run whose record cannot be read and what to do next, as a missing child or a broken link already gets, with no stack trace. An unreadable signal wait is already handled this way (wait_unreadable).
Steps to reproduce
- Run a parent workflow whose nested workflow step suspends on a child (a gate or a wait_for_signal step in the child).
- Corrupt the child's run record file so it is not valid YAML.
- Run swamp workflow resume on the parent run.
Actual: a YAML parse error with a stack trace. Seen locally; the same resolver is used through swamp serve.
Note
swamp-club#3110 reads the same nested runs when it builds the suspended event, and there a failed read is logged and leaves the field off.
Shipped
Click a lifecycle step above to view its details.
Sign in to post a ripple.