fix(migration): phase 122 workflow parse crash + executor false-pass detection#25
Merged
khaliqgant merged 1 commit intomainfrom Apr 23, 2026
Merged
Conversation
…e detection
Two bugs caught the hard way during the first phase-122 run on
2026-04-23:
1. workflows/122-cloud-cutover-phase3b.ts:133 — the 90-min soak loop
embeds a shell `for i in $(seq 1 90); do ... echo "soak: ${i}/90";
done` inside a JS template literal. JS eagerly interpolates ${i}
at module-load time — but `i` is a shell variable, not a JS one,
so Node throws ReferenceError before the workflow runtime starts.
Escape the shell interpolation (\${i}) so the loop text reaches
the shell verbatim.
2. scripts/run-rs256-migration.sh:261 — the earlier detection patch
greps for [run:failed] / workflow] FAILED: / : failed$. Those
markers are emitted by the agent-relay workflow runtime, so a
parse-time crash (bug #1) slips past them: the runner script
prints its stack trace to stderr, agent-relay's wrapper swallows
the exit code to 0, and the executor reports "✓ 122 workflow
passed" and opens a PR with whatever unrelated files happened to
be in the working tree. Add Node error names (ReferenceError,
TypeError, SyntaxError, RangeError) as an additional detection
pattern so parse/load-time crashes fail loudly.
Both bugs were required to silently commit empty (but wrong) work
to a HIGH-risk production phase. Either alone would have been
caught. Fixing both.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two bugs caught the hard way while trying to run phase 122 on 2026-04-23. Either alone would have stopped us; both together silently committed empty (but wrong) work to a HIGH-risk production phase.
Bug 1: phase 122 workflow crashes at parse time
`workflows/122-cloud-cutover-phase3b.ts:133` has this inside a JS template literal:
```$(seq 1 90); do ... echo "soak: $ {i}/90 min"; done
for i in
```
Node's template-literal interpolation eats `${i}` at module-load time, but `i` is a shell loop variable — not a JS one — so the import throws `ReferenceError: i is not defined` before the workflow runtime starts.
Fix: escape the shell interpolation so `\\${i}` reaches the shell verbatim.
Bug 2: executor reports success for a parse-time crash
`scripts/run-rs256-migration.sh:261` already scans for `[run:failed]` / `[workflow] FAILED:` / `: failed$`. Those markers are emitted by the agent-relay workflow runtime — so a parse-time crash (bug #1) slips past them:
Fix: add Node error names (`ReferenceError`, `TypeError`, `SyntaxError`, `RangeError`) as an additional detection pattern.
Not in this PR but related
Test plan
🤖 Generated with Claude Code