remix
remix copied to clipboard
Remix crashes with web-fetch 4.3.2/1.8.2
What version of Remix are you using?
1.8.2
Steps to Reproduce
See sandbox: https://codesandbox.io/p/sandbox/solitary-wave-1l0skr Failing test PR: https://github.com/remix-run/remix/pull/4994
- Observe exit code 1 (remix crashes, premature close error) when fetcher loads from /load.tsx route, which calls fetch from a Google drive URL
- Go to load.tsx, uncomment the import that uses web-fetch 4.3.1
- Remix no longer crashes
Expected Behavior
web-fetch's fetch should work, without crashing remix, returning a valid HTML result
Actual Behavior
remix crashes, exit code 1
/project/sandbox/node_modules/@remix-run/node/node_modules/@remix-run/web-fetch/src/fetch.js:342
const error = Object.assign(new Error('Premature close'), {
^
Error: Premature close
at TLSSocket.onSocketClose (/project/sandbox/node_modules/@remix-run/node/node_modules/@remix-run/web-fetch/src/fetch.js:342:33)
at TLSSocket.emit (node:events:525:35)
at node:net:757:14
at TCP.done (node:_tls_wrap:584:7)
error Command failed with exit code 1.
Related issues:
https://github.com/remix-run/remix/issues/4737
This codesandbox URL you shared doesn't seem to work; I've had this challenge when using their newer codesandbox environments 😅
Any way you could copy code into this stackblitz template below?
- Remix Stackblitz 1.8.2 template: https://stackblitz.com/edit/node-nrd9zz
Hi, can you explain what you mean by the codesandbox doesn't work? It is supposed to show an error that is the bug I am reporting:
once you go into load.tsx and uncomment the 4.3.1 web-fetch import, and hit the refresh icon "restart task" on the dev pane, then it will display the site:
Unfortunately i cannot repro this issue in Stackblitz, it has its own issues with fetching (different from the issue i'm reporting), guessing from CORS bc it's webcontainer?
Here's a failing test PR if that helps: https://github.com/remix-run/remix/pull/4994
Hi, can you explain what you mean by the codesandbox doesn't work? My bad, i should have been more specific; when I try to view the codesandbox URL you shared I see this error & do no have access to view the code in the images you shared

Here's a failing test PR if that helps: https://github.com/remix-run/remix/pull/4994
@jacob-ebey Is the failing test enough? Anything else we can do to help get this fixed?
I have an action that starts a setInterval that calls fetch and for me this reproduces the error every few requests. Luckily reverting @remix-run/web-fetch back to 4.3.1 fixes the issue.
I'm having the same issue. I just closed #5385 as it's a dupe of this issue.
~~If you need to temporary workaround (it works for me), you can use the diff I posted there with patch-package. No guarantees, but it seems to work until we get a proper fix (all I do is suppress the error).~~ I use the "revert back to 4.3.1" solution.
Interesting that my issue is with fetching from docs.google.com as well (I saw the failing test in #4994). Google must be doing something funky.
@tarngerine Just to confirm, I can see your sandbox properly failing with 4.3.2
FYI... Here's the diff between 4.3.1 and 4.3.2
fetch.js
diff --git a/src/fetch.js b/src/fetch.js
index v4.3.1..v4.3.2 100644
--- a/src/fetch.js
+++ b/src/fetch.js
@@ -346,13 +346,8 @@
}
};
- socket.prependListener('close', onSocketClose);
-
- request.on('abort', () => {
- socket.removeListener('close', onSocketClose);
- });
-
- socket.on('data', buf => {
+ /** @param {Buffer} buf */
+ const onData = buf => {
properLastChunkReceived = Buffer.compare(buf.slice(-5), LAST_CHUNK) === 0;
// Sometimes final 0-length chunk and end of message code are in separate packets
@@ -364,6 +359,14 @@
}
previousChunk = buf;
+ };
+
+ socket.prependListener('close', onSocketClose);
+ socket.on('data', onData);
+
+ request.on('close', () => {
+ socket.removeListener('close', onSocketClose);
+ socket.removeListener('data', onData);
});
});
}
request.js
diff --git a/src/request.js b/src/request.js
index v4.3.1..v4.3.2 100644
--- a/src/request.js
+++ b/src/request.js
@@ -38,6 +38,7 @@
* @property {string} method
* @property {RequestRedirect} redirect
* @property {globalThis.Headers} headers
+ * @property {RequestCredentials} credentials
* @property {URL} parsedURL
* @property {AbortSignal|null} signal
*
@@ -135,6 +136,7 @@
method,
redirect: init.redirect || input.redirect || 'follow',
headers,
+ credentials: init.credentials || 'same-origin',
parsedURL,
signal: signal || null
};
@@ -169,7 +171,7 @@
*/
get credentials() {
- return "same-origin"
+ return this[INTERNALS].credentials
}
/**
The only issue with reverting back to 4.3.1 is that 4.3.2 was there to fix a memory leak (see https://github.com/remix-run/web-std-io/commit/3b9b38446d186230a94d5481ba12ae4289d8809e).
PR created with a possible fix: https://github.com/remix-run/web-std-io/pull/29
Plz review
I'm surprised that something that crashes Remix isn't getting any attention.
I'm running into the same issue - it's only with specific websites. Looks like there's a similar problem with the node-fetch library? https://github.com/node-fetch/node-fetch/issues/1576
I installed axios and am able to make requests to the same website that was causing an error with Remix's web-fetch implementation 😞
FWIW, I also came here to report similar issue. I have also run into it often but it's not consistent.
Like the other commenters, we have experienced this issue in our Remix project. It was very inconsistent, with identical requests failing consistently one after another one minute, then seemingly working fine the next. I was never able to replicate the issue locally: we had to catch it in production.
Replacing our usage of fetch with axios seems to have completely fixed the problem.
Let me know if I can provide any details of our project that might help debug. I just wanted to bump this issue for visibility.
The error does not occur if you have connection: keep-alive in the headers. I think axios sets that automatically.
This is resolved by the version bump in #7026 and should be available when 1.19.2 is released
This can also be tested in 1.19.2-pre.0 currently if anyone would like to validate the fix
🤖 Hello there,
We just published version 1.19.2-pre.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!
Thanks!
🤖 Hello there,
We just published version v0.0.0-nightly-3b808ce-20230802 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!
Thanks!
We've had this issue (intermittently on prod only) and we've updated to 1.19.2-pre.0 and are testing it out now. Will update this issue if we continue to experience the Premature close error
🤖 Hello there,
We just published version 1.19.2-pre.1 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!
Thanks!
@brophdawg11 was there really something related to this issue in 1.19.2-pre.1, and should we upgrade to try it?
🤖 Hello there,
We just published version v0.0.0-nightly-7cb1e7e-20230803 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!
Thanks!
@ericallam No - I think that's just our bot seeing that there's something new in the prerelease when compared to the latest stable release, so it comments from the comparison of 1.19.0 -> 1.19.1-pre.0 and 1.19.0 -> 1.19.1-pre.1
Has 1.19.0-pre.0 been working ok for you w.r.t. the fetch crash?
@brophdawg11 no errors so far 👍
🤖 Hello there,
We just published version 1.19.2-pre.2 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!
Thanks!
🤖 Hello there,
We just published version 1.19.2 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!
Thanks!