Conversation
#174 produced four occurrences and, between them, four test names. Nothing else. The state that would explain it was all on the daemon side and none of it survived: `wait_with_output` is never reached, so the child's output is dropped in the unwind, and the run's journal was never read at all. On a missing dispatch the test now attempts to terminate the resumed child and reaps it, then reports its stdout, its stderr, and the run's journal entries with seq, type and step. The child may be STALLED or may have ALREADY EXITED, and the two are indistinguishable from the test's side -- which is exactly why the dump matters. #174 turned out to be the second case: the resume died instantly with `run_not_found` while the test waited 60s on it. An earlier revision of this message asserted the child "is still running" and was "wedged by definition", which contradicted the very failure it described; the helper terminates and reaps either way, discarding both results because "already gone" is a normal outcome here rather than an error. The journal is the important half. The question a missing dispatch raises is whether the daemon resumed and stalled partway or never resumed at all, and nothing else answers it. The listing covers the CURRENT segment, which is what `journal_entries` scans -- every entry these non-compacting crash tests produce, though not every entry under compaction. This is what found #174's root cause: a run whose journal existed but whose registry row did not, because `Engine::start` registers last. Fixed in #177. Verified by forcing the read ceiling to 1ms: before-first: no step.dispatch after resume: timed out after 1ms waiting for a protocol frame; the daemon sent nothing (see #174) --- resume child --- stdout (0 bytes): stderr (0 bytes): --- journal (1 entries) --- seq=1 type=RunSpawned step=None sha256 19f3431a -> 361572ef -> restored 19f3431a, no 1ms literal left in the tree. Measured at THIS head, on main after #175 and #177: workspace 152 passed, 0 failed, no warnings; crash_resume 34 passed in 37.98s. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR Session-Id: c228933d-4f94-4d83-9a9a-daf3c83b94f1
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughCrash-resume tests now capture resume dispatch errors instead of unwrapping them. A shared helper terminates the resume process, collects stdout and stderr, and reports current journal state in labeled panic diagnostics. ChangesCrash Resume Diagnostics
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
Warning Some tools did not complete. Review the errors below. 🔧 Clippy (1.97.1)Clippy execution failed Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Essentials by visiting https://app.coderabbit.ai/settings/billing. Comment |
merged Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR Session-Id: c228933d-4f94-4d83-9a9a-daf3c83b94f1
Replaces #176, which GitHub auto-closed when #175 merged and its base branch was deleted. Same change, rebuilt directly on
mainnow that both #175 and #177 have landed.Why
#174 produced four occurrences and, between them, four test names. Nothing else. The state that would explain it was all daemon-side and none of it survived:
wait_with_output()is never reached, so the child's output is dropped in the unwind, and the run's journal was never read.What it does
On a missing dispatch the test attempts to terminate the resumed child and reaps it, then reports its stdout, stderr, and the run's journal entries with
seq,typeandstep.The child may be stalled or may have already exited, and those are indistinguishable from the test's side — which is exactly why the dump matters. #174 turned out to be the second: the resume died instantly with
run_not_foundwhile the test waited 60s on it.The journal is the important half. The question a missing dispatch raises is did the daemon resume and stall, or never resume at all? Nothing else answers it. The listing covers the current segment — every entry these non-compacting crash tests produce, though not every entry under compaction.
This is what found #174's root cause, fixed in #177.
Evidence
Forcing the read ceiling to 1ms:
sha256
19f3431a→361572ef→ restored19f3431a, no 1ms literal left in the tree.Measured at this head: workspace 152 passed, 0 failed, no warnings;
crash_resume34 passed in 37.98s.Signoff: local 3-lens preswarm at this head — maintainability / history / structure all REVIEW_PASSED. The history lens caught that an earlier message asserted the child "is still running" while also describing a child that had already exited; that contradiction is corrected in both the message and the code comment.
🤖 Generated with Claude Code
https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR