build: name the dying command when the cache wrapper fails - #201
Conversation
The wrapper runs under set -euo pipefail with a silent setup phase, so any probe or lock failure exits with a bare code and zero output. CI's Rust Check / Shared job has died that way six times in one day (~90 seconds in, exit 1, nothing between the env group and the error line), and every rerun passes, so the cause is invisible. An ERR trap now prints the exit code, line, and command to stderr. Successful runs stay exactly as quiet as before. Co-Authored-By: Nova (Claude Fable 5) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan includes up to 1 review per rolling hour; 0 remain after this review. 📝 WalkthroughWalkthroughThree shell scripts now report failure diagnostics when ChangesFailure diagnostics
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This localized change only improves failure diagnostics in the cache wrapper while preserving successful-run output, so no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The CI failure timeline shows the silent exit-1s land in the build-wrapper-test step, not the clippy step they were first blamed on: the clippy step completes half an hour before the silent death in the affected runs, and the wrapper test suites run under set -e with no trap of their own. Both suites now carry the same ERR trap as the wrapper. Intentional failure assertions run inside conditionals, where bash suppresses ERR, so expected failures stay quiet and only unguarded deaths get named. Co-Authored-By: Nova (Claude Fable 5) <noreply@anthropic.com>
1 participant
💜 What
One ERR trap in
scripts/cargo-cache-build.sh: when anything in the wrapper's setup phase dies underset -e, stderr now carries the exit code, the line number, and the exact command. Successful runs produce no new output.🔮 Why
The Rust Check / Shared CI job has failed six times in one day with the same signature — roughly 90 seconds in, exit 1, and literally zero output between the env group and the error line. Every rerun passes. The wrapper's setup phase (cache probes, sccache config locking) is silent by design, so whatever dies leaves no name behind. The next occurrence will identify itself, which converts the flake sidequest from guesswork into a one-line fix.
The trap covers exactly the silent region: the script hands off to the wrapped command with
exec, so wrapped-command failures were never the silent ones — cargo reports those itself.🧪 Verification
bash -nclean. A passing invocation (cargo --version) produces byte-identical output to before. Injecting afalseinto the setup phase of a copy producescargo-cache-build.sh: exit 1 at line 31: falseon stderr where the unpatched script says nothing.🤖 Generated with Claude Code
Summary by CodeRabbit