build will yield "Failed to set fetch cache" #53695
Comments
|
Hi, can you share additional details, full error stacks if available? Could you check if this was an issue in |
|
Hello. I came across a thread in stackoverflow, link down below: [next.js fetch request gives error TypeError: fetch failed](https://stackoverflow.com/questions/74165121/next-js-fetch-request-gives-error-typeerror-fetch-failed) The thread mentioned about the building Node environment, which gave me a hint. Failed to set fetch cache URL { I then move to another of our linux servers where I upgraded the Node env to v18.17.0. And the problem went away. So I do think there's something to deal with the Node env. Maybe the stackoverflow thread could help you dig into the problem too. |
|
More note on the Node env, Later on I downgraded Node to 16, problem came back. 👌 |
|
had to downgrade to 13.4.12 |
Same issue here - local build has I can confirm that for me using Error is still present with latest canary build The error i see is |
|
I am also seeing this issue on Amplify with 13.4.13. Builds and runs fine on localhost without seeing the error. Downgrade to 13.4.12 allowed the build to work fine on Amplify. |
|
Still getting this in latest Canary I believe this pull request may be responsible #53030 I'm not able to get a minimal reproduction to fail with same error. Is there anything else I can provide here to help get to the bottom of the issue - we are left unable to upgrade from 13.4.12 |
|
Updating nextjs to 13.4.16 seems fixed the problem. |
No, problem is now deeper. The build process will not prompt error. But the production site will not be usable and browser log shows error. Down grade to 13.4.12 works. 😓 |
|
We are experiencing a similar issue in production after upgrading to 13.4.13, but not at the build time of ssg pages but of ssr pages. |
|
We solved upgrading to node |
|
Upgraded node but still facing this issue on latest canary release. Any further progress? |
|
Had to downgrade Next to 13.4.9. Wish they wouldn't ship these features without a test or a note on the docs if anything additional needs to be configured when upgrading |
|
Ditto. Comes across as sloppy and careless. Wasting most of my development time chasing bugs vs building features |
|
on the back server in the logs comes the following error if disable caching - fetch( |
|
no any solutions? |
|
I also had the same error and downgrading to 13.4.12 worked, but the versions above it all got this error. So what is the solution to this? |
|
I think downgrading is the solution for now. I dare say the whole 13 release was rushed. For example, previously you could use getStaticProps to generate a blurHash for an image in a component. Now, if you're using the app router you use an await/async function instead, but this will cause hydration issues as your component waits to be hydrated before the blurHash is returned. Additionally, the grouping of routes (like_so) with different root layouts causes numerous hydration issues. This, in addition to other numerous bugs, has me seriously considering going back to the page router on 12. If there was an option to pay (say $100 a year) to get a more thoroughly tested framework, I would 100% take it. |
|
Seeing similar too on 13.4.19 and node 18.17.1. Getting a bunch of these errors: |
|
Something I noticed today when upgrading another project - after upgrading beyond 13.4.12 when I run npm run dev I get the following displayed in console
in 13.4.12 and below I get
So it seems to be losing the hostname? I am not running a custom server in any way, just standard setup |
|
I also got this issue on next 13.4.19, downgrading to 13.4.12 makes it go away |
|
I am having the same or similar issue with Here's my error message: However, I am seeing this additional message in the Terminal after I downgraded to v13.4.12
// tsconfig.json
{
"compilerOptions": {
"target": "es5",
"lib": [
"dom",
"dom.iterable",
"esnext"
],
"allowJs": true,
"skipLibCheck": true,
"strict": true,
"noEmit": true,
"esModuleInterop": true,
"module": "esnext",
"moduleResolution": "bundler",
"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve",
"incremental": true,
"plugins": [
{
"name": "next"
}
],
"paths": {
"@/*": [
"./*"
]
},
"forceConsistentCasingInFileNames": true
},
"include": [
"next-env.d.ts",
"**/*.ts",
"**/*.tsx",
".next/types/**/*.ts"
],
"exclude": [
"node_modules"
]
}Here's what TypeScript has on this Hope this will help with coming up with a patch in the next update! |
|
This bug is currently no one cares and fix it? Or is it because this error is sometimes encountered and sometimes not encountered? |
I am also encountering this issue. The node version is 18.17.1 and I tried Next 13.4.19 and 13.4.20-canary.23, but it's still happening. Downgrading to 13.4.12 fixed the problem. |
|
Using
Similar issues in 2 different forms of logs: and Resolved downgrading the next.js version to 13.4.12 |
|
Getting similar on Node 18.17.1 and Next 13.4.19 when running dd-trace in a startup script: |
|
Having this issue on 13.5.1. :( |
|
Encountering it on latest, node version is 20.2.0. So node version seems to be irrelevant in this issue. |
|
Maybe there's an architectural reason I'm missing, but what is the point of going through the HTTP stack to perform IPC (inter process communication)? If the two processes are on the same host (which seems the case with the default |
|
Yes, that is why I'm not sure to understand, but maybe they are able to distribute the server functions across different nodes (virtual or physical) that is why I think they are using HTTP. The main problem is, that I'm upgrading an entire website to Next.js 13 because Vercel is forcing me to update the Node.js version, but I will not be able to finish my rework if we still have that big issue. Next.js should prioritize that in my opinion, with a fix or provide the right way to handle that if is not a bug. |
|
@FerrariAndrea the function is being used to set the cache, basically it receives the response of a fetch you do in the app, and pass it using GET to god knows where, so if fetch is unable to handle this, as this is wrapped in a try/catch statement, the catch is being called just throwing to the console "Failed to set fetch cache" as a warning, that is why the process does not fail, but not sure what are the consequences of this not working well, probably it just disables de data cache for the specific fetchs failing. |
|
How exactly does this error impact production server? Does it disable cache for errored route and force new requests for every page visit? |
|
@Arctomachine the new next architecture relies on this cache mechanism to dedupe requests because the idea is that you can call the exactly same request N times but because you are using the cache, you don't have to do N same requests, in the way Next 13 App Router is build, this is pretty common because you possibly are going to call the same endpoint to render the page, and also for the metadata (because they are different functions), and others, so without the cache you are going to have higher network loads and maybe reach to API limits if you project is too big. So what would happen if the cache fails, is that in scenarios where you have N different fetches, if there are fetches with different revalidation time, it will still get everything again because there is no cache, only the fetches with big responses are not being cached, with that you could assume which of your requests are not being cached and calculate the impact on your project. |
|
I tested different canary versions of 13.4.13, this error starts between canary 3 and 4: v13.4.13-canary.3...v13.4.13-canary.4 Canary <4, error -4094 Canary 4+, error -4077 Canary 16 only |
|
For some reason it gives entirely different error on my production server (ubuntu 20 or 22, node 18). Same code that gives -4077 on local machine (win 10, node 20) |
|
@Arctomachine for me I first see "failed to set fetch cache", then following the one you are showing. |
|
any update on this? I see the same error on |
|
I think I might have encountered the longer error in different scenario too. At least it had similar syntax. |
…s#53695, seems like you need to downgrade. downgrading to 13.4.12
|
[FYI] Versions
|
Yes, but I can't split my API in chunks, it is sad that we have a payload limit on the new version of Next.js. |
|
Can confirm this issues persists in the latest release (14.0). In addition, as highlighted by others building a SSG site of 2k pages takes SIGNIFICANTLY longer now. 13.4.12 is the latest release that works our end. Not only is failed to set fetch/build cache gone, but the build time is 6mins vs 45mins..... This seriously needs addressing, either as a fix or some clear documentation on why there is such a significant performance downgrade beyond 13.4.12. |
|
upgraded to 14.0.0 and happy to save anyone the trouble... it still doesn't work |
|
Would be great to see this issue receive some attention. I've had to roll back 11 sites to 13.4.3. The worst part of this issue is that it often doesn't result in a failed production deployment but will result in client-side errors to the live site. Are others getting failed |
|
@shuding ? 🤞😅 |
|
I have residual |
|
I think this issue doesn't impact the client when we see the In simple words, for every request that fails like that, we are just not using the cache, as if we disable the cache for these requests. |
|
This error breaks entire static page on revalidation. It gives blank white page on next visit. So it is not just "cache not working", it is "whole site is not working" |
A shared incremental cache IPC server was introduced for build-time static workers as an optimization to dedupe fetch requests, however this can cause fetch-related flakiness to builds under certain conditions (e.g., large payloads). This moves the optimization behind an experimental flag to unblock those running into IPC-related build time errors while we work on an alternative solution for the underlying issue Fixes #53695
|
In latest canary cache works. But it brings back occasional old error -4094, as mentioned in my previous comments. Breaks nothing seemingly, but clutters build logs and error is still error, after all. |
|
Any plan to fix it in 13.5.X ? |
|
Guys, I tested the last canary 14.0.2-canary.9 and seems to be fixed |
|
Guys, This is absolutely correct, I updated to |
|
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
and others
Verify canary release
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 Binaries: Node: 18.17.0 npm: 9.8.1 Yarn: N/A pnpm: N/A Relevant Packages: next: 13.4.13 eslint-config-next: 13.4.13 react: 18.2.0 react-dom: 18.2.0 typescript: 5.1.6 Next.js Config: output: N/AWhich 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 or a replay of the bug
/~https://github.com/vercel/next.js/
To Reproduce
"npm run build" with 13.4.13 will yield "Failed to set fetch cache" for some fetch calls.
the same code works fine in 13.4.12.
Describe the Bug
"npm run build" with 13.4.13 will yield "Failed to set fetch cache" for some fetch calls.
the same code works fine in 13.4.12.
Expected Behavior
should be the same as in 13.4.12
Which browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response
The text was updated successfully, but these errors were encountered: