next.js: build will yield "Failed to set fetch cache"

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.

Ditto. Comes across as sloppy and careless. Wasting most of my development time chasing bugs vs building features

I also got this issue on next 13.4.19, downgrading to 13.4.12 makes it go away

Failed to set fetch cache URL {
  href: 'http://127.0.0.1:8055/path-1/path2?slug=someslug',
  origin: 'http://127.0.0.1:8055',
  protocol: 'http:',
  username: '',
  password: '',
  host: '127.0.0.1:8055',
  hostname: '127.0.0.1',
  port: '8055',
  pathname: '/path-1/path2',
  search: '?slug=someslug',
  searchParams: URLSearchParams {
    'slug' => 'some-slug' },
  hash: ''
} TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at async globalThis.fetch (F:\frontend\node_modules\next\dist\server\lib\patch-fetch.js:93:16)
    at async invokeRequest (F:\frontend\node_modules\next\dist\server\lib\server-ipc\invoke-request.js:17:12)
    at async invokeIpcMethod (F:\frontend\node_modules\next\dist\server\lib\server-ipc\request-utils.js:45:21)
    at async F:\frontend\node_modules\next\dist\server\lib\patch-fetch.js:292:29 {
  cause: Error: read ECONNRESET
      at TCP.onStreamRead (node:internal/stream_base_commons:217:20)
      at TCP.callbackTrampoline (node:internal/async_hooks:130:17) {
    errno: -4077,
    code: 'ECONNRESET',
    syscall: 'read'
  }
}

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.

any update on this? I see the same error on v13.5.6

Guys, I tested the last canary 14.0.2-canary.9 and seems to be fixed

Sadly, I am using Contentful CMS, so it is not a localhost issue, at least for me.

Having problems with response payload size, I remove some fields from the graphQL fields producing payload size differences and this is the result.

A 16.2 KB payload size = no problem. A 40.87 KB payload size = error.

I wonder if there is a way to just disable fetch cache and instead use the graphql client cache without loosing all Next capabilities, the problem in my case is that I am using Urql and it uses the “fetch” modified version of next with the cache.

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. 😓

More note on the Node env,

Later on I downgraded Node to 16, problem came back. Then again upgraded Node to 18, problem went away.

👌

Guys, This is absolutely correct, I updated to "next": "^14.0.2-canary.25", using this code npm install --save next@canary and the issue was solved, next js is not stable right now for many major changes, hopefully they will fix the issue ASAP

@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.

Looks like this is the problem:

https://github.com/vercel/next.js/blob/f77f222d4f75f755e99837853d20609b478cd4c1/packages/next/src/server/lib/server-ipc/request-utils.ts#L48

Inside args, there is the body of the response, and it is being sent in the URL (oh no!) using GET, probably gonna fail if the response is big.

Also not sure if encodeURIComponent can deal with a language like german.

But basically what I am seeing from calling this fetch is the following error:

statusText: 'Request Header Fields Too Large',

So I asume we need to tell fetch to handle bigger headers or use a different approach.

Good info, I have 7 similar projects, and I only have problems with the one that fetches more data from the same GraphQL API.

Good info, I have 7 similar projects, and I only have problems with the one that fetches more data from the same GraphQL API.

Yes, I think this is relevant because I’m using GraphQL as well and I have several requests too.

GraphQL is not the problem, I have an api using nodejs and laravel having the same problem

I am having the same or similar issue with next build returning an error message.

Here’s my error message:

Failed to set fetch cache https://graphql.contentful.com/content/v1/spaces/.... TypeError: terminated
    at Fetch.onAborted (node:internal/deps/undici/undici:11000:53)
    at Fetch.emit (node:events:513:28)
    at Fetch.terminate (node:internal/deps/undici/undici:10272:14)
    at Object.onError (node:internal/deps/undici/undici:11095:36)
    at Request.onError (node:internal/deps/undici/undici:6477:31)
    at errorRequest (node:internal/deps/undici/undici:8440:17)
    at Socket.onSocketClose (node:internal/deps/undici/undici:7895:9)
    at Socket.emit (node:events:513:28)
    at TCP.<anonymous> (node:net:298:12)
    at TCP.callbackTrampoline (node:internal/async_hooks:132:17) {
  [cause]: SocketError: closed
      at Socket.onSocketClose (node:internal/deps/undici/undici:7883:35)
      at Socket.emit (node:events:513:28)
      at TCP.<anonymous> (node:net:298:12)
      at TCP.callbackTrampoline (node:internal/async_hooks:132:17) {
    code: 'UND_ERR_SOCKET',
    socket: {
      localAddress: undefined,
      localPort: undefined,
      remoteAddress: undefined,
      remotePort: undefined,
      remoteFamily: undefined,
      timeout: undefined,
      bytesWritten: 40751,
      bytesRead: 313
    }
  }

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
compilerOptions: forceConsistentCasingInFileNames

Hope this will help with coming up with a patch in the next update!

I also got this issue on next 13.4.19, downgrading to 13.4.12 makes it go away

Failed to set fetch cache URL {
  href: 'http://127.0.0.1:8055/path-1/path2?slug=someslug',
  origin: 'http://127.0.0.1:8055',
  protocol: 'http:',
  username: '',
  password: '',
  host: '127.0.0.1:8055',
  hostname: '127.0.0.1',
  port: '8055',
  pathname: '/path-1/path2',
  search: '?slug=someslug',
  searchParams: URLSearchParams {
    'slug' => 'some-slug' },
  hash: ''
} TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at async globalThis.fetch (F:\frontend\node_modules\next\dist\server\lib\patch-fetch.js:93:16)
    at async invokeRequest (F:\frontend\node_modules\next\dist\server\lib\server-ipc\invoke-request.js:17:12)
    at async invokeIpcMethod (F:\frontend\node_modules\next\dist\server\lib\server-ipc\request-utils.js:45:21)
    at async F:\frontend\node_modules\next\dist\server\lib\patch-fetch.js:292:29 {
  cause: Error: read ECONNRESET
      at TCP.onStreamRead (node:internal/stream_base_commons:217:20)
      at TCP.callbackTrampoline (node:internal/async_hooks:130:17) {
    errno: -4077,
    code: 'ECONNRESET',
    syscall: 'read'
  }
}

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.

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

We solved upgrading to node 18.17.0. For us, it was related to a memory leak described here

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”

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 set fetch cache in successful production builds with client-side errors?

upgraded to 14.0.0 and happy to save anyone the trouble… it still doesn’t work

[FYI] In my case, It’s fixed when I reduced response size. temporary solution though.

Versions

• node v18.14.0
• next v13.5.6

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. Anyway, I totally understand that the new version of Next.js changes a lot from the old one, so I understand that it is really hard to manage all the issues and needs that people have. So I will just wait for a fix and big thx for the work that the Next.js team is doing

@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.

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 fetchHostname), and running in a Node.js runtime, a socket or a named pipe could be used instead.

I came across this issue while fixing up on-demand revalidation for dynamic routes.

With Node 16 and Next 13.3.0, everything was fine. Starting with Next 13.4.13-canary.4 (the PR mentioned above), I got Failed to set fetch cache http://localhost:1337/graphql TypeError: fetch failed with code: 'UND_ERR_SOCKET', but in the end still a successful build.

Switching to Node 18.18.0 (with Next 13.3 through 13.5), I got networkError: TypeError: fetch failed with code: ECONNREFUSED and no build.

Finally, I replaced localhost/graphql with 127.0.0.1/graphql in the endpoint of the apollo client. There’s still some unreproducible networkError: TypeError: fetch failed with code: ECONNRESET but build is successful, including with Next 13.5.2.

And yes, things are somewhat different on Ubuntu vs macOS. Oh well.

Updating nextjs to 13.4.16 seems fixed the problem.

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. The node env on my laptop is v18.17.0 (npm 9.8.1), I can build the site just fine. But when I move to our Linux server, where the node env is v16.20.1 (npm 9.8.1 too though), the build would give “Failed to set fetch cache”, more detail about the error like down below (I’ve marked out the ip with [marked-out-ip-here] for security reason):

Failed to set fetch cache URL { href: ‘http://`[marked-out-ip-here]/gateway-eatz/portal/api/stock/category', origin: 'http://[marked-out-ip-here]', protocol: 'http:', username: '', password: '', host: '[marked-out-ip-here]', hostname: '[marked-out-ip-here]`’, port: ‘’, pathname: ‘/gateway-eatz/portal/api/stock/category’, search: ‘’, searchParams: URLSearchParams {}, hash: ‘’ } TypeError: fetch failed at Object.fetch (/home/epb/Work/GIT/portal-nxt3/node_modules/next/dist/compiled/undici/index.js:1:26669) { cause: SocketError: other side closed at Socket.onSocketEnd (/home/epb/Work/GIT/portal-nxt3/node_modules/next/dist/compiled/undici/index.js:1:63301) at Socket.emit (node:events:525:35) at endReadableNT (node:internal/streams/readable:1358:12) at processTicksAndRejections (node:internal/process/task_queues:83:21) { code: ‘UND_ERR_SOCKET’, socket: { localAddress: ‘127.0.0.1’, localPort: 36280, remoteAddress: ‘127.0.0.1’, remotePort: 35063, remoteFamily: ‘IPv4’, timeout: undefined, bytesWritten: 24479, bytesRead: 370 } } }

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.