[Bug?]: /_server request gets stuck with async code inside middleware

[JesseVelden]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

With the new @solid/start, the /_server request gets stuck and shows (pending) as status in Chrome's Network Inspector when using async code inside the middleware. When not using async code, it works fine.

Expected behavior 🤔

The request resolves

Steps to reproduce 🕹

Steps:

1. Go to https://codesandbox.io/p/devbox/solid-start-middleware-for-server-with-promise-session-not-working-6kz3tm?file=%2Fsrc%2Fmiddleware.ts%3A31%2C57
2. Run the dev server
3. Click on Generate New button in the preview window, and see the that the code actually executes the console.log but the request hangs as can be seen Network Inspector
4. If you uncomment the async code inside the middleware.ts, you can see it does work as expected

Context 🔦

Middleware is needed for checking if a user is logged in. It is uses async functions to do that

Your environment 🌎

Node.js v20.9.0

    "@solidjs/router": "^0.10.5",
    "@solidjs/start": "^0.4.1",
    "solid-js": "^1.8.7",
    "vinxi": "0.0.54"

[nksaraf]

Yup very peculiar. Will have to debug this carefully.

[edivados]

@nksaraf I think the issue is this.

The middleware in front of the server function creats a FetchEvent which calls toWebRequest creating a ReadableStream from the request body.

solid-start/packages/start/server/middleware.ts

Lines 59 to 62 in a9b4b05

	function wrapRequestMiddleware(onRequest: RequestMiddleware) {
	return async (h3Event: H3Event) => {
	const fetchEvent = getFetchEvent(h3Event);
	const response = await onRequest(fetchEvent);

If I understand it correctly the unreleated await gives node a chance to read chunks and later we get stuck trying to read a request body that has already been read.

solid-start/packages/start/config/server-handler.js

Lines 102 to 103 in a9b4b05

	parsed = fromJSON(await readBody(event), {
	plugins: [

I verified this by replacing toWebRequest with a Proxy and not reading the body.

solid-start/packages/start/server/middleware.ts

Lines 20 to 25 in a9b4b05

	export function createFetchEvent(event: H3Event<EventHandlerRequest>): FetchEvent {
	return new Proxy(
	{
	request: toWebRequest(event),
	clientAddress: getRequestIP(event),
	locals: {},

[nksaraf]

Ohh I think I faced something similar here: unjs/h3#570

Okay I think we should do the proxy approach anyway so that nothing is called lazily.

[edivados]

ah interessting... you already ran into that.

So we would proxy the WebRequest and make sure the body is not read eagerly right?
While testing I just left url in tact because something was relying on it.

[nksaraf]

I wonder if we should push this upwards to vinxi's server utils as well

[nksaraf]

Pulling this upstream into vinxi: nksaraf/vinxi#101