fix: bound Cursor Connect frame buffering - #844
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
CI follow-up: the initial macOS failure was the same Bun 1.3.14 Trace/BPT trap / bun.report signature seen on unrelated PR #841. The failed job passed on rerun, while the other platform jobs were already green. No code change was needed. |
|
Maintainer triage: this is a narrow and valuable hardening change. It bounds inbound Cursor Connect frame buffering and rejects incomplete streams instead of allowing unbounded or ambiguous framing state. The branch currently conflicts with Because this is co-maintainer-authored, an independent non-author review is still required before landing. Thanks for keeping the scope focused. |
Summary
Part of #820. The 32 MiB inbound limit matches the repository existing framing-hardening design note (
devlog/_fin/350_cursor-provider-add/116_phase33-connect-framing-robustness-plan.md).Verification
bun test tests/cursor-framing.test.ts tests/cursor-hardening.test.ts tests/cursor-live-transport.test.ts(45 pass)bun run typecheckbun run privacy:scanCompatibility
Normal split headers, split payloads, and multiple frames per chunk preserve their order. A legitimate inbound frame larger than 32 MiB now fails explicitly; outbound framing remains unchanged.