fix(node): prevent body-read crashes and wire corruption#228
Conversation
…adapter Batch of Node-adapter crash/corruption fixes from the v1 stabilization review: - F1: the non-middleware branch of callNodeHandler had no `.catch`, so an async handler that threw caused an unhandledRejection and never settled (request hung). Mirror the middleware branch's `.catch(reject)`. - F2: a second `text()`/`json()` after the buffered fast path re-listened to an already-ended IncomingMessage and hung forever. Track body consumption at the srvx level and reject with `TypeError: Body is unusable`. - F3: the `_request` getter wrapped the consumed stream in a native Request, throwing "... disturbed or locked" and poisoning `bodyUsed` / `clone()` / `formData()` / `blob()` / `mode` / `referrer`. Serve `bodyUsed` from srvx state and never materialize a native Request over a disturbed stream. - F5: `DataView` view bodies sent the whole underlying ArrayBuffer while content-length was the view length, corrupting the response and leaving stray bytes in keep-alive connections. Slice to the view's window. - GET/HEAD are now always null-body per the fetch spec, regardless of what was on the wire and regardless of property-access order. Co-Authored-By: Claude Fable 5 <[email protected]>
|
Warning Review limit reached
Next review available in: 51 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 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 |
commit: |
2 participants
Batch of Node-adapter crash/corruption fixes from the v1 stabilization review.
callNodeHandler's non-middleware branch had no.catch; an async handler that threw caused an unhandledRejection and the request hung forever. Now mirrors the middleware branch's.catch(reject).text()/json()after the buffered fast path re-listened to an endedIncomingMessageand hung. Body consumption is now tracked at the srvx level and a second read rejects withTypeError: Body is unusable._requestgetter wrapped the consumed stream in a nativeRequest, throwing "… disturbed or locked" and poisoningbodyUsed/clone()/formData()/blob()/mode/referrer.bodyUsedis now served from srvx state and no nativeRequestis materialized over a disturbed stream.DataViewview bodies sent the whole underlyingArrayBufferwhilecontent-lengthwas the view length, corrupting the response and leaving stray bytes in keep-alive connections. Now sliced to the view's window (Buffer.from(b.buffer, b.byteOffset, b.byteLength)).request.runtime.node.req).Tests added in
test/node-adapters.test.tscover each finding (verified to fail on the unpatched source). Full suite: 858 passed, 32 skipped.🤖 Generated with Claude Code