test(runtime-host): reject a handshake with a mismatched compatibility epoch - #3136
Conversation
…y epoch A Host that announces a different compatibility epoch must be refused before any domain command is admitted. Cover the live Host hello check and a forged accepted frame on the Client connect path.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan includes up to 3 reviews per rolling hour; 2 remain after this review. 📝 WalkthroughWhat this solvesAdds handshake-level regression tests for mismatched runtime host The tests verify that:
Design assessmentThis extends the existing handshake and host-kernel test suites. It does not add a parallel production path or change public declarations. The solution is the smallest coherent change for the issue. The forged transport peer is necessary because both normal endpoints use the same compile-time epoch. The added helpers support framed I/O, temporary resources, lifecycle control, and cleanup for that test seam. No deletion or simplification is apparent without weakening regression coverage. Risks and validationThe diff adds tests only. It does not change user-visible runtime behavior, public contracts, security behavior, licensing, releases, or governance controls. The stated validation includes Review-relevant risksNo protected-area effect was identified in the current diff. The person performing the merge must review the final diff, and a maintainer makes the final determination. WalkthroughThe pull request adds handshake compatibility tests for incompatible compatibility epochs. The tests cover forged-peer rejection, expected epoch reporting, connection closure, blocked domain commands, and cleanup. ChangesHandshake compatibility coverage
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This change adds coverage for compatibility-epoch handshake rejection without changing production behavior. No actionable merge-blocking risk remains beyond normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Thanks for the test — the forged-peer scaffolding is a nice end-to-end seam (no production test hooks), both tests verify the post-rejection state (connection closed / no domain requests admitted), and the Conclusion: PASS with one P2. P2-1 — the real upgrade flow that #3126 depends on has no test; the PR's tests cover only two seams. Optional nits (P3): the AI-assisted review disclosure: this review was produced with AI assistance (pi review subagent on 中文摘要(AI 辅助审查)结论:PASS(1 个 P2)。伪造 peer 的端到端脚手架是好的接缝(无生产测试钩子),两个测试都验证拒绝后的状态(连接关闭 / 无 domain 请求被受理),epoch |
|
LGTM — merging. The P2-1 note (no test for the real upgrade-flow AI-assisted review disclosure: this merge decision follows the review comment above (pi review subagent on |
Summary
exchangeRuntimeHostHandshakealready rejects a peer whosecompatibilityEpochdiffers, and later work depends on that rejection keeping a mismatched Host away from domain commands. That path had no handshake-level test:host-kernelonly covered an incompatible protocol range, and both ends share the compile-time epoch constant.This adds two seams:
compatibilityEpoch + 1is answeredincompatible, then the connection is closed so a follow-uphost.statuscannot be admitted.acceptedwith a different epoch while the registration file stays current.connectRuntimeHostreturnsunavailable/handshake_failed, and the peer never receives a domain request.Fixes #3130
Test plan
@maka/runtime-hosttypecheckhandshake-compatibility(1/1)host-kernel(46/46), including the new epoch-mismatch case