Repository navigation
test: report the sibling-recycle child's state when it stalls - #6893
Conversation
The connected-sibling recycle case spawns a Bun child with piped stdout and stderr and, until the replacement wait, never looked at either. On Windows CI the child once wrote no readiness marker for 45.9 s and the test failed with a bare timeout, leaving no trace of what the child was doing (#4956 family). Drain both pipes from spawn into bounded buffers and append the child's pid, exit code and recent output to every wait's timeout. The replacement wait no longer opens a second reader on an already drained stream. Refs #4956
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
✅ Deterministic PR hygiene checks passed. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to This change only improves failure diagnostics in a test and does not alter production behavior. It carries no identified merge risk. Pre-merge checks |
|
Summary
The "an ended link recycles a connected sibling after listener cleanup" case in
tests/clients/client-link-runtime.test.tsspawns a Bun child with piped stdout and stderr and, until the last wait, never reads either. On Windows CI the child once wrote no readiness marker for 45.9 s (run 38041407670, attempt 3, windows 6/9); the test failed withtimed out waiting for connected client readinessand nothing about the child. That is the #4956 signature: the process exists and shows no progress. The same case passed on the job rerun.This makes the next occurrence diagnosable instead of silent:
child.stderr, which would conflict with the drain's reader lock.No production code changes. This does not claim a cause for #4956 (Bun already reads spawned pipes eagerly, so an unread pipe is not established as the stall), and the issue should stay open.
Refs #4956
Verification
bun test tests/clients/client-link-runtime.test.ts: 6 pass, 0 fail (macOS).bun run typecheck: exit 0.Checklist
Summary by CodeRabbit