fix(webapp): precise S2 record cap + CORS 413 on session append#3720
fix(webapp): precise S2 record cap + CORS 413 on session append#3720ericallam wants to merge 2 commits into
Conversation
|
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis PR adds per-record metered-size enforcement to realtime session append operations. The S2 service layer now exports size constants and a Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
Summary
Two improvements to session
.in/append:TypeError: Failed to fetch. App-side retry-on-disconnect loops no longer spin forever on a permanently-rejected payload.Design
S2 enforces a per-record metered size of
8 + 2*H + Σ(header name + value) + body ≤ 1048576bytes. With no record headers (our case), the budget reduces tobody ≤ 1048568. Verified empirically against cloud S2 — append succeeds at metered=1048576 and 422s at 1048577 withrecord must have metered size less than 1 MiB.The old
MAX_APPEND_BODY_BYTES = 512 KiBwas derived by assuming worst-case JSON escape doubling (every byte becomes\"or\\), giving(1 MiB - overhead) / 2. Safe, but rejects ~half the legitimate input space.The new flow:
S2RealtimeStreams.#appendPartByNamecomputesBuffer.byteLength(JSON.stringify({data: part, id: partId}), "utf8") + 8and throwsS2RecordTooLargeError(aServiceValidationErrorwith status 413) if it would exceed S2's ceiling. The route's existing error branch maps the throw to a 413 with a descriptive message.The 413 CORS fix is a single-line change in
apiBuilder.server.ts—wrapResponsewas being skipped on the body-too-large branch; every other error branch wraps; the 413 was the exception.Test plan
[1048568, 1048569, ..., 1048576]and across H ∈ {0, 1×5 hdr bytes, 1×14 hdr bytes} — the formula matches exactlystatus: 413(noTypeError: Failed to fetch)