next js 13 server error " TypeError: fetch failed " #54961
Comments
|
Maybe related to #51605 |
balazsorban44
added
the
please verify canary
|
Please verify that your issue can be recreated with Why was this issue marked with the
|
|
This is not a new issue. This has have been happening since roughly 13.2.x However it seems to have gotten worse since 13.4.19. For me on windows, i'm getting now 1 crash per day on my development environment. In the past the next server would restart which was nice, but now i have to manually restart. Also it seems to be less of a problem on mac. If you search there might me some tips in similar topics. In general development on windows with Next 13 is far from optimal |
|
I have the same problem, in my case is when I'm sending files from (5 - 20mb) to supabase storage. const uploadResult = await storageClient
.from(STORAGE_BUCKET)
.upload(filePath, file, {
contentType: `video/${fileExt}`,
upsert: true
}); |
|
Confirming that this has been driving me nuts lately. really frustrating building in NextJs lately. |
|
@balazsorban44 I'm using canary btw
|
|
The problem seems getting worse when NextJs got rid of node-fetch (compiled) and exclusively used undici. It happened since v13.4.x. What may also be useful is to provide a benchmark for the performance of NextJs API routes. Is there information about for example the rate limit of the API routes? Essentially, API is API. |
|
Anyone saying "same issue", or not posting helpful comments to debug, please note that adding a reproduction link helps us verify/investigate more than anything. Stating your Next.js version in itself or an out-of-context code snippet is not very helpful. 🙏 Please comment your reproduction repository instead, we would like to investigate! I added the label @cosieLq For anyone, upgrading Node.js might be a good start to verify if it's related or not. 👍 |
|
Adding a link to a Git Project which can replicate the same issue, I tested it by using Node 16 and 18, Git Project, It may require some test supabase credentials to work but does the job to replicate the issue. Error: And another medium link where a similar issue has been explained and "tried" to fix |
|
@balazsorban44 I don't have a codebase to prove that it is indeed "getting worse". It's just my guess. I'm working on a project with NextJs v13.2.4. We were trying to upgrade it to v13.4.x. And then in the production environment, the "TypeError: fetch failed" showed up so often (~1 per minute) that we had to roll it back. Then after a bit searching, I found these issues: #51605 #53353 , thinking that these issues are somehow related to our problem. In our case, the error codes differ ("ECONNREFUSED" and "ECONNRESET"). They take place after calling on our NextJs API route. I'm not sure if it's a (upstream) bug or not. It has something to do with load. That's why I'm also curious about the performance of NextJs API routes. Are there guidelines hereof? |
|
A reproduction that works consistently for me: Repo go to http://localhost:3000/pool/137:0x21988c9cfd08db3b5793c2c6782271dc94749251/smart open the file change Might have something to do with a client component under a server component? Wild guess. Noticed this line in the log a couple seconds before it started erroring out (both times I tried this repro): Finally, the error itself: |
|
I tried yesterday the last Canary version while using Node 18 and it worked. |
|
For some reason my repository random stalled out and started having this issue on |
|
@balazsorban44 I wish I could provide more details, I basically found it difficult to work in dev mode. I downgraded to 13.4.13 and it's been stable since. I might test out the canary version once I roll my current implementation out. hopefully, someone else may have provided more context before then. |
|
Hi, Just wanted to chime in to say we're experiencing the same symptoms in our application. We recently upgraded next.js from 13.4.7 to 13.4.19. Node version 18.7.1. We see steady increase in memory usage culminating in a I'm going to try rolling back next.js and let it run for a day or two. |
|
This problem happens with Fastify servers work fine, but it just happens with Next.js servers. P/S Downgrade to |
|
Updated from 13.4.10 to 13.4.19 and now get this error |
|
This issue seems pretty similar: |
|
This issue continues happened with the latest ^13.4.19 version with my m1 machine in development mode, it happens randomly. |
|
For all the people who have been reporting that it happens with Next.js v13.4.19, please upgrade to the latest canary on the Releases page (currently (I am also experiencing this issue on the latest canary personally, but would be good to get some other data points) |
|
I recently switched to version 13.4.20-canary.23 and encountered an unexpected type error that read "X TypeError [ERR_INVALID_STATE]: Invalid state: ReadableStream is already closed". I'm unsure of what caused this error, as there is no backend portion to my next.js project. 
|
|
cross-posting in case it helps: Eventually we do want to benefit from image optimization, but at this point the memory footprint is simply too high. |
Hello @karlhorky , I have been facing the same issue with Next.js v13.4.19, (Node.js v18.16.0). it is happening frequently. It restarts in less than 5 minutes of starting the server. I am new to Next.js and How do I upgrade to the canary release? |
See here for updating to canary release. Or you can directly replace the version of |
Okay, Thank you @Elvincth |
|
I'm getting this same error after upgrading to
Our solution proxies calls to an external https API server (that's run locally in the dev environment). We were getting a similar error in the past and our investigation pointed to extending Node's local certificates by using the Note: if we downgrade to Next Thanks in advance for any guidance on this. EDIT: I tested this with |
|
Also getting this. First on The following two errors alternate in my console: Only on I temporarily resolved it by just skipping the default image loader, but that is not the long term solution. I want the default loader for it's optimisations haha // next.config.js
...
images: {
loader: 'custom',
loaderFile: './bin/imageLoader.js',
},
...
// imageLoader.js
'use client';
export default function imageLoader({ src, width, quality }) {
if (src.includes('?')) {
return `${src}&w=${width}&q=${quality || 75}`;
}
return `${src}?w=${width}&q=${quality || 75}`;
} |
|
@GoudekettingRM Downgrade to 13.5.2 => It should be fine. |
|
Thanks for the quick reply, same issues on 13.5.2 unfortunately... |
|
Still the same on 13.5.3. Revert to 13.4.x works around it, but it had a severe bug pertaining to locales that was fixed only a few days ago, iirc. So, it's a matter of choose the lesser evil, at least for the moment 😟 |
|
I noticed the same issue as @pealmeid , I have something in place on my system that sets The cause of this issue is this PR: #55775. There you can see that A simple reproduction is to put an export in your login shell that sets If you put a console.log in next.config.js you can see I don't think it helps or solves the original problem of this issue, perhaps this should be a separate issue. *edit There is apparently an experimental way to do https with nextjs locally ( |
|
Also following here.. having the same issue as of today, locally. Haven't tried to deploy my project, but have tried all of the workarounds listed here, and still no luck. |
|
Just read through every post. They're all about different issues and most are not caused by Next.js but by application code. As a first step upgrade to the latest stable version of Next.js, for example what #54961 (comment) and other shared has already been fixed. Though unable to reproduce we were able to just remove that code path altogether so that specifically can't happen anymore. TLDR: Next.js no longer uses fetch in the hot path while rendering, whereas in 13.4 it did, so this error can't happen in the normal rendering path. For others I'm seeing a bunch of different issues being confused:
Hope that provides enough context! |
|
Thanks for this explanation @timneutkens. |
|
@timneutkens In the end, if all it takes is to downgrade Next.js to 13.4 (down from 13.5), you can't reasonably assume the problem is in application code. In such case, it doesn't matter if the url Isn't not application code or something getting blocked or whatever else, it is purely Next.js that has put extra unneccesary checks in place for the certificate. And frankly, on a development environment, I don't give 2 tosses about the correctness of certificates. If I could work without https, I would, but when I can't, I just don't care about certificates. I'm on a development machine, and I just need to do my job instead of messing around with certificates that have always worked perfectly fine. I don't think that's all that unreasonable, that a developer just wants to get his/her work done, and not have to deal with certificate bollocks. Therefor it's super unproductive to restrict certificate requirements further than they already were. That is of course, for my version of this problem. Other versions may enjoy different argumentation. |
|
Thanks for the expansive answer @timneutkens. Not quite sure about the wrt optimizer though. If I skip it, the images load without error - i.e. the images exist and are reachable. As soon as I use the default optimizer it errors with |
Same problem here. It's a production build, running on windows using a corporate proxy. To setup the proxy we were setting up HTTPS_PROXY env var As it was not enough, ignore in some internal requests, we use node --require to preload some code. In this case globalAgent. It worked ok, until undici got into the scene and needed to use the same preloaded code to setup the proxyagent on the global undici object. And now, since 13.4.13, we get the ECONN_REFUSED on the image optimizer requests. Just downgrading after 13.4.12, everything works ok. So it looks like NextJs, has problems with corporate proxies as we always have to look for workarounds PS: all custom code requests works, just internal requests done by NextJS, fail. So probably our scenario is not on the list by @timneutkens |
|
@timneutkens You're evaluation on bullet point 3 I think is just wrong. There are numerous comments here and in the previous thread describing this issue, and it isn't coming from our code. I repeat. We never see these fetch failed while we hit our own pages... they appear in the logs later, often after the process has been up for hours. In our specific example I have tried load testing the application for an hour handling hundreds of thousands of requests and there are 0 fetch failed. Yet, our production logs are absolutely full of them, when I'm hitting the same exact URL. There is some sort of internal mechanic going on which is triggering the fetch failed. It aligns with what many of the commentators here are bringing up, and unfortunately I have zero confidence the Next team even thinks this is an issue. |
|
Like I said most are caused by application code, not all. If you're still running into this after upgrading please provide a full reproduction so that we can investigate it further, unfortunately there is no runnable reproduction provided in this issue so far besides the ones mentioning the stacktrace with code that no longer exists. As said the majority of comments posted on this issue cannot happen anymore as we got rid of the code path being referenced, it no longer exists in 13.5. Looking forward to looking at a reproduction. |
I was hoping there will be a response for mine as well. the same codebase I have been working on since next 11, now can no longer be upgraded beyond 13.4.12, without either the fetch issues or completely fails to build on 13.5.x I still have no clue what to change except to downgrade back to 13.4.12 |
|
@harrisyn others already replied to your case , which is to open a new issue with a reproduction: #54961 (comment) We're unable to help in the majority of cases where the only information shared is a stack trace, please provide a full repository that we can run to investigate. Adding the label so that the comment is posted that will be useful for you to read. |
timneutkens
added
the
please add a complete reproduction
|
We cannot recreate the issue with the provided information. Please add a reproduction in order for us to be able to investigate. Why was this issue marked with the
|
|
@timneutkens Also, this error occurs starting from a certain version. If it occurred starting from a specific version of the same code, it would be difficult to say for sure that it was a problem with the users' application code. When looking at the differences between versions as shown in the link below, it appears that undici has been applied starting from v13.4.13. Also, it appears that a similar issue has been open in undici for quite a long time ago. (issue link nodejs/undici#1602) From the user's perspective, there is no way to prepare for the sudden occurrence of an error when the patch version is updated from the semantic version. We are sorry that we have difficulty providing you with our product code. Probably, it would be difficult for most companies to provide service codes. |
|
For our apps the But I realize that we have a non-standard configuration for the Next.js Custom Server Can't promise for sure that it will help, but maybe worth a shot to try to configure the hostname (not sure how to configure it if you're not using a Custom Server). const app = next({
- hostname: 'localhost',
+ // Use '127.0.0.1' instead of 'localhost' to temporarily work around issues
+ // with ECONNREFUSED (connection refused) errors with high port numbers
+ // https://github.com/vercel/next.js/issues/51684#issuecomment-1609345705
+ //
+ // TODO: Revert to 'localhost' when the issue is resolved https://github.com/vercel/next.js/issues/51684
+ hostname: '127.0.0.1',
Other references, potentially useful:
|
|
@karlhorky I can't reproduce this issue with the latest Next.js canary. Perhaps updating would solve the problem? Seems that this issue was happening because Next.js' IPv6 handling was... weird back then. Also, just saying, but I don't see how |
Nice, removing the I'll keep an eye out for any intermittent |
|
@karlhorky I'd say that the fix for that issue and some PRs after that screwed up Next.js' IPv6 handling even further, so yeah. Got fixed real good after that though, should work properly starting from 13.5 :) I fixed that IPv6 handling, but there were some issues after I got that in (13.4.16). They got rid of the render workers some time after that, which fixed those issues as well (13.4.20-canary.24). |
|
Tim has given a thorough explanation and what to provide/check in #54961 (comment) After that comment, all the following comments were talking about 13.4, while it was pointed out to check with 13.5 The OP's issue has been fixed, as the whole code path of that source of issue has been removed altogether. There might be mixed problems in this issue (some might be bugs), but those should have a dedicated bug report, with a minimal reproduction that we can investigate! (Keep in mind that We understand if you cannot provide your company's source code, but that's not what we were asking for either, as it might not be the best reproduction anyway. Please read: #54961 (comment) I will close this issue now, but feel free to open a new one - after testing with the latest version of Next.js - with something that we can investigate, we would like to work on all verified Next.js bugs! 🙏 |
and others
Link to the code that reproduces this issue or a replay of the bug
https://github.com/AhmedShehata98/shoperz
To Reproduce
TypeError: fetch failed
at Object.fetch (node:internal/deps/undici/undici:11576:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async invokeRequest (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\server-ipc\invoke-request.js:17:12)
at async invokeRender (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\router-server.js:254:29)
at async handleRequest (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\router-server.js:447:24)
at async requestHandler (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\router-server.js:464:13)
at async Server. (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\start-server.js:117:13) {
cause: Error: connect ECONNREFUSED ::1:58392
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1495:16) {
errno: -4078,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '::1',
port: 58392
}
}
Current vs. Expected behavior
i followed the server start instractions by " npm run dev " I expected its works fine without error but got error
TypeError: fetch failed
at Object.fetch (node:internal/deps/undici/undici:11576:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async invokeRequest (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\server-ipc\invoke-request.js:17:12)
at async invokeRender (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\router-server.js:254:29)
at async handleRequest (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\router-server.js:447:24)
at async requestHandler (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\router-server.js:464:13)
at async Server. (D:\my-work\Progo-soft\libya-zon\node_modules\next\dist\server\lib\start-server.js:117:13) {
cause: Error: connect ECONNREFUSED ::1:58392
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1495:16) {
errno: -4078,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '::1',
port: 58392
}
}
Verify canary release
Provide environment information
Operating System: Platform: win32 Arch: x64 Version: Windows 10 Pro Binaries: Node: 18.17.1 npm: N/A Yarn: N/A pnpm: N/A Relevant Packages: next: 13.4.19 eslint-config-next: 13.4.19 react: 18.2.0 react-dom: 18.2.0 typescript: 5.2.2 Next.js Config: output: N/AWhich area(s) are affected? (Select all that apply)
Not sure
Additional context
No response
The text was updated successfully, but these errors were encountered: