Repository navigation
test(cli): let the forged sibling-env start bind its own port - #7740
Conversation
freeLoopbackPort() releases its probe before the pinned child binds; a port taken in between makes the pinned start wait out port reclaim past the 45 s Windows deadline with no runtime record (dev run 40183909309). The forged-env case checks sibling admission, not a port number, so it now binds through config.port 0. Timeouts report the child's output and last record.
|
✅ Deterministic PR hygiene checks passed. |
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. |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Runtime port selection and readiness tests/cli/cli-start-journal-order.test.ts |
startSibling accepts an optional port and validates the runtime-record port. Readiness checks use the reported port. If waiting for the record fails, the helper kills a running child and includes launch details and bounded output tails in the error. The forged-port test lets the child use its configured port. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Other
Merge Risk: 
Minimal · up to 0df85
-
The sibling-port test change is mergeable; no concrete current-head risk remains.
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passed -
Finishing Touches: 💡 1
-
📝 Generate docstrings: 💡
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
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 @coderabbitai help to get the list of available commands.
…safe Log only allowlisted runtime-record fields (the record carries the per-process attestationSecret), rethrow an early-exit error unchanged since its stderr is already consumed, and catch synchronous Response construction failures in the bounded tail reader.
|
Maintainer dev integration record (release 2.93 dev-merge loop), per the MAINTAINERS.md maintainer-integration exception for dev. This is maintainer integration, not an approving review.
|
Summary
Fixes the only failure in dev Cross-platform CI run 40183909309 (windows 9/9, job 121140589969):
a direct start cannot claim sibling status with only a forged port envtimed out with "timed out waiting for sibling runtime record" while the childocx startwas still alive.Root cause is a port race in the test, not a product regression.
freeLoopbackPort()releases its probe socket before the child is spawned, and the child is hard-pinned with--port. If another process on the runner (Windows shards run four Bun pools) takes that port in between, the pinned start waits in port reclaim for up to 60 s (src/cli/index.tsport selection →reclaimListenPort, then a further 5 s availability wait) and only publishes its PID/runtime record after binding (src/cli/start-ownership-publication.ts). The 45 s CI deadline (watchdogMs(10_000)on win32) expires first, leaving exactly the observed state.The forged-env case checks sibling admission, so it does not need a predetermined listener port. It now starts without
--portand binds its own port through the fixture'sconfig.port: 0.startSiblingaccepts an unpinned start and takes the bound port from the runtime record. Every pinned caller keeps the exact port-equality check, and the PID, readiness PID,readystatus and absentsiblingOfPortassertions are unchanged. No timeout was raised and no retry was added.When the record never appears, the error now includes the requested port, the child PID, the last record read, and stdout/stderr tails, so a future stall can be diagnosed from the CI log.
Verification
Evidence for the root cause, from a separate investigation at dev 8ebe46b with the pinned Bun 1.4.4:
exitCode=null runtime=null pidFile=false. After the port was released at 48 s, a matching record appeared at 50.15 s. With the port held permanently, the child logged "still busy after prefer-retry; refusing ephemeral fallback" at 67 s and exited 1 at 72 s.OCX_SIBLING_OF_PORTprobe blocking.honorSiblingMarkerstrips both env fields andconsumeSiblingHandoffreturns false immediately without a nonce.On this branch (Windows, Bun 1.4.4):
bun test --isolate tests/cli/cli-start-journal-order.test.ts: 6 pass / 0 fail (forged case 4.2 s)bun run typecheck: passbun run privacy:scan: passgit diff --check: cleanThe same release-then-pin pattern exists at other pinned call sites in this file and in
sibling-home-client-sync,ocx-launcher-runtimeandcli-start-auxiliary-bind. Those cases assert on a specific port, so they are left unchanged here.NOT RUN: full
bun run test(test-only change to one file); Windows Cross-platform CI on this head (manual dispatch after merge, per CI policy).Checklist
Summary by CodeRabbit