Cloning of response leads to issues

[benmccann]

This line:

kit/packages/kit/src/runtime/server/page.js

Line 128 in 8805c6d

const clone = response.clone();

Causes issues in Node where it dies unexpectedly without any message on server. The Node high water mark limit is much smaller than browser. Can increase high water mark as workaround

There's multiple issues talking about this in node-fetch (e.g. 671 and 151). Their recommendation is to stream and provide back pressure: node-fetch/node-fetch#151 (comment)

[Rich-Harris]

If someone can create a repro it would help a lot

[benmccann]

There was a comment on Discord that they're only reproducing this if the request goes through Nginx: https://discord.com/channels/457912077277855764/819723698415599626/823759556789272597

The explanation they gave: "it's not so easy to reproduce because it depends on how the HTTP servers split responses into TCP packages. node split it into 2 TCP packets, python into 2, and nginx into 4. inside node-fetch getting loop I can catch one or two TCP packets before it's hanging. then I increased Nginx proxy buffers from 8k to 32k this problem was gone."

[stalkerg]

@Rich-Harris yes, self-locking happens here https://github.com/sveltejs/kit/blob/master/packages/kit/src/runtime/server/page.js#L141

If an HTTP packet contains more than two TCP packages (the first packet is usually the header) and one of these TCP packages for the body did not fit into the write buffer.
Basically, await clone.text() waiting for a response from the stream, but this stream waiting drying (reading) buffer by original response what can't be returned from the function because we waiting await clone.text().

Basically, const clone = response.clone(); can work only if all tcp package for HTTP body fit into write buffer OR JS interpretation/compiler/VM smart enough to detect self-locks what NodeJS not.

[Rich-Harris]

Is there any way to interpret this other than 'fetch is fundamentally broken'?

[stalkerg]

If you talking about sveltekit fetch - then yes.
PS one more link whatwg/streams#506 (comment)

[benmccann]

The way to fix this problem is to resolve the cloned response in parallel with the original. For example:

const fetch = require('node-fetch');

const response = await fetch('https://example.com');
const r1 = await response.clone();

const results = await Promise.all([response.json(), r1.text()]);

The response in SvelteKit is used in two places:

1. it's serialized and put into the page for hydration
2. it's used in the server-side implementation of load as desired by the user

The problem here is that we're trying to do these basically in serial by basically intercepting the response.

I can't think of a way to read the stream in the two places in parallel while maintaining our current API. The issue is that load takes fetch as a parameter, so we can't call load and serialize the response in parallel.

So as much as I hate to say it, I think that SvelteKit's load implementation is fundamentally broken and I don't think there's a way to fix it while keeping our current API. The only thing I can really think at this point is that we probably made the wrong decision in #268 and should go back to a Sapper-like implementation where the user can handle the fetch response however they like and then they hand it off to us. At that point we can take the user's response and in parallel render the Svelte components and serialize the data for hydration

This is why we're in beta and not final release 😁

[Rich-Harris]

So as much as I hate to say it, I think that SvelteKit's load implementation is fundamentally broken and I don't think there's a way to fix it while keeping our current API

o ye of little faith #635

[Conduitry]

Proxies are truly the Spanish Inquisition of js language features.