solidjs / solid / 34311858741

72%

main: 89%

push

github

fix(web): rebuild the buffered server-function request from its parts (#3312)


Fixes #3311. Under Nitro, srvx hands `handleServerFunctionRequest` a lazy `NodeRequest` that only wears `Request.prototype`: `instanceof Request` is true, but the native constructor never ran. `bufferBodyWithin` put the buffered bytes back with `new Request(request, { body })`, which reaches into undici's private state and threw, and the bare `catch` around the buffering relabelled that as 400 "Malformed server function arguments". Every POST server function under Nitro failed with the default `bodySizeLimit`, whatever the arguments were.

- `bufferBodyWithin` now returns the bytes, and `withBufferedBody` rebuilds the request from its url, method, headers and signal — the parts the runtime already reads to get this far. srvx's lazy headers iterate fine through that path. (srvx's documented `request._request` fallback does not work here: its getter builds from the already-consumed stream and throws "body object should not be disturbed or locked".)
- Only the counting read stays under the 400. A failure to put the bytes back is the runtime's own step and surfaces as its own error instead of the caller's malformed arguments.
- Regression spec `server-functions-adapter-request.spec.tsx` models the srvx trait with a `setPrototypeOf` class over a real Request (and asserts the copy constructor throws on it), pins that the capped POST dispatches with the app-facing `event.request` intact and still readable, and that a rebuild failure is not relabelled as a 400.
- Patch changeset for `@solidjs/web`.

Closes #3311

516 of 784 branches covered (65.82%)

Branch coverage included in aggregate %.

768 of 1002 relevant lines covered (76.65%)

14.97 hits per line