Using Undici as node fetch polyfill causes fetch failed #48744
Comments
|
+1 to this. I'm on I'm using Apollo Client Nextjs for This error doesn't happen in local dev env. |
Someone even made a demo showcasing this issue, bless them |
|
Any known workaround for this? |
|
@julioxavierr using |
|
Ran into similar issues - weirdly enough in |
I wrote that, you're welcome :)) |
|
Thanks @kaloyanBozhkov and @nevolgograd for this! Unfortunately, it didn't solve my problem. I have an app with a middleware/auth layer using |
|
I' m also seeing this error, but it seems to be in the context of a server action failing to redirect. I have a server action that does this: Which throws: |
|
Also having this issue in the redirect. I've created a reproduction here It seems like if I pin next to |
|
I started to see this too in server actions async function handleForm(formData: FormData) {
'use server';
const { error } = await updateProject(projectId, formData);
const errorParam = error ? `&errorMessage=${error}` : '';
redirect(`/projects/${projectId}/edit?tab=edit${errorParam}`);
}content-length is 2 on the response but body is empty 
|
|
I'm having the same issue with a redirect inside a server action |
|
I'm having the same issue as well. |
|
Same issue calling fetch in getServerSideProps using pages directory. Function Region: Stockholm, Sweden (North) - arn1 TypeError: fetch failed |
|
facing the same issue in simple api writing to vercel postgres. fetch failed: TypeError: fetch failed "next": "13.4.7", |
|
same issue here failed to get redirect response TypeError: fetch failed |
|
I am also seeing the same issue when redirecting to a page from a server action |
|
I'm facing the same issue here |
|
I am using fetch in a sveltekit server func and having I think this same issue |
|
I ran into this same issue when using - "next": "^13.4.12",
+ "next": "13.4.7",I have tested this fix with the development server inside a |
See vercel/next.js#48744 (comment) for more information.
+1 on this. Also having an issue while redirecting from a server action. Downgrading to 13.4.7 seems to fix it |
|
+1, needs to be fixed ASAP |
|
Same issue here. Works on 13.4.7 but not on 13.4.13 (using signIn function from next-auth on a custom login page). |
|
Same issue with me - downgrading to 13.4.7 fixed it. |
|
This started for me today too on 13.4.13 |
|
Today, I encountered the identical error using version 13.4.13. While working in Postman, I unintentionally included a body in a GET request to my API handler. Consequently, the server produced the same error as mentioned by others earlier. SolutionDowngrading to version 13.4.7 solved the issue |
|
Getting this locally when cloning the Supabase template https://vercel.com/templates/next.js/supabase. Reproducible on the login page which calls the form actions.
|
|
I'm also getting the same error when sending a DELETE request with a This is the stacktrace: TypeError: fetch failed
at Object.fetch (node:internal/deps/undici/undici:11457:11)
at async invokeRequest (/Users/julien/projects/valence/polaris-hub/node_modules/next/dist/server/lib/server-ipc/invoke-request.js:21:12)
at async requestHandler (/Users/julien/projects/valence/polaris-hub/node_modules/next/dist/server/lib/start-server.js:336:33)
at async Server.<anonymous> (/Users/julien/projects/valence/polaris-hub/node_modules/next/dist/server/lib/start-server.js:152:13) {
cause: RequestContentLengthMismatchError: Request body length does not match content-length header
at write (node:internal/deps/undici/undici:9949:41)
at _resume (node:internal/deps/undici/undici:9927:33)
at resume (node:internal/deps/undici/undici:9829:7)
at connect (node:internal/deps/undici/undici:9818:7) {
code: 'UND_ERR_REQ_CONTENT_LENGTH_MISMATCH'
}
}
Downgrading to Might be related to #51874, that landed in |
|
I have an inbound PR that fixes it |
|
@davecarlson's PR was landed on stable 👍 |
|
Seeing lots of undici issues across multiple projects on latest next and latest node 18: |
|
Keep in mind that Undici is the underlying name of |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
and others
Verify canary release
Provide environment information
Which area(s) of Next.js are affected? (leave empty if unsure)
Data fetching (gS(S)P, getInitialProps)
Link to the code that reproduces this issue
next.js/packages/next/src/server/node-polyfill-fetch.ts
Line 6 in e601a3b
To Reproduce
Ensure project is using serverless functions that are from the frankfurt network (so far I know this one causes the problem, but maybe others do as well)
Below are my steps, but they should be entirely optional since replicating this is possible in different ways.
have a next api endpoint that fires a tRCP call using tRPC's client
call the endpoint
observe that fetch failed because of undici (node fetch polyfill)
Describe the Bug
Big thanks to TillaTheHun0 for reporting this.
I want to make a bug report since I replicated and can confirm his thesis.
Next has a node polyfill for fetch, which uses either undici or node-fetch depending on an environment variable called __NEXT_USE_UNDICI. This env variable is likely set by Vercel depending on which network the Serverless Functions are configured to execute on.
I tested countless times, and the thing that solved my problems was indeed changing the network location of my serverless functions in my Project Settings on Vercel.
Undici currently has some issue (RequestContentLengthMismatchError), partially documented here. This issue is causing all sorts of problems from different places since this fetch polyfill is used by many other tools.
In my case it was tRPC complaining, with:
though I read around different places people encountering the same problem in various ways.
We should either use only one polyfill (the working one) while waiting for undici to be patched, or we should allow people to explicitly choose which polyfill they'd like through configuring __NEXT_USE_UNDICI somewhere. Though I have a feeling that going with either option could be impossible if there's unknown limitations to the machine running the Functions that make it so undici is chosen over node-fetch.
Regardless, it is currently a fact that the "Project Settings" > "Functions" page (on Vercel) does not have any information about this behaviour. At the very least we should inform users that there's environment variables that could change depending on the chosen region for the Serverless Functions. Optimally we should provide a list with environment variables and their configuration for the different regions, and ideally also how these map to certain behaviours. At the very least this would speed up debugging and problem solving IMO. (this part might not be specific to the Next repo though)
Expected Behavior
fetch requests should not fail like this, regardless of which serverless function they are running on.
Which browser are you using? (if relevant)
N/A
How are you deploying your application? (if relevant)
N/A
The text was updated successfully, but these errors were encountered: