build will yield "Failed to set fetch cache"

[fwcontact]

Verify canary release

• [X] I verified that the issue exists in the latest Next.js 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/A

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

[ijjk]

Hi, can you share additional details, full error stacks if available? Could you check if this was an issue in v13.4.13-canary.4 but not in v13.4.13-canary.3?

[fwcontact]

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.

[fwcontact]

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.

👌

[VladSturm]

had to downgrade to 13.4.12

[Alshie]

Hi, can you share additional details, full error stacks if available? Could you check if this was an issue in v13.4.13-canary.4 but not in v13.4.13-canary.3?

Same issue here - local build has Failed to set fetch cache errors. Builds on Vercel do not exhibit this error but builds now take ~15 minutes vs 3 minutes on 13.4.12

I can confirm that for me using 13.4.13-canary.3 the issue is not present and it appears to be introduced in v13.4.13-canary.4

Error is still present with latest canary build 13.4.14-canary.1

The error i see is

[   =] - info Generating static pages (120/213)Failed to set fetch cache URL {
  href: 'https://xxxxx',
  origin: 'https://xxxxxx',
  protocol: 'https:',
  username: '',
  password: '',
  host: 'xxxxx',
  hostname: 'xxxxx',
  port: '',
  pathname: 'xxxxx',
  search: 'xxxx',
  searchParams: URLSearchParams {
    'page' => '1',
    'size' => '30',
    'sortType' => '0' },
  hash: ''
} TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11) {
  cause: Error: write EPIPE
      at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16)
      at WriteWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
    errno: -32,
    code: 'EPIPE',
    syscall: 'write'
  }
}

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.6.7
      Yarn: 1.22.19
      pnpm: 7.12.0
    Relevant Packages:
      next: 13.4.13-canary.4
      eslint-config-next: 13.4.12
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.6
    Next.js Config:
      output: N/A

[BarrySaikSoundry]

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.

[Alshie]

Still getting this in latest Canary

I believe this pull request may be responsible https://github.com/vercel/next.js/pull/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

[fwcontact]

Updating nextjs to 13.4.16 seems fixed the problem.

[fwcontact]

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

[alfredosalzillo]

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.

{
   "level":50,
   "time":1692185221832,
   "pid":29,
   "hostname":"xxxx-xxxx-xxx",
   "dd":{
      "trace_id":"1299599159201377670",
      "span_id":"7281736072001716225",
      "service":"xxxx",
      "version":"1.18.2",
      "env":"production"
   },
   "error":{
      "cause":{
         "name":"SocketError",
         "code":"UND_ERR_SOCKET",
         "socket":{
            "localAddress":"127.0.0.1",
            "localPort":53260,
            "remoteAddress":"127.0.0.1",
            "remotePort":46689,
            "remoteFamily":"IPv4",
            "bytesWritten":6186,
            "bytesRead":165042
         }
      }
   },
   "type":"error",
   "msg":"TypeError: fetch failed"
}

[alfredosalzillo]

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

[oliverkidd]

Upgraded node but still facing this issue on latest canary release. Any further progress?

[osehmathias]

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

[oliverkidd]

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

[Tekutorukushi]

on the back server in the logs comes the following error

SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /api/v1/settings/  !!!
uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 306] during GET /api/v1/settings/ 
OSError: write error

if disable caching - fetch(${process.env.NEXT_PUBLIC_API_URL}/settings/, { cache: 'no-store' }) - , then there is no error and the project is built. if set - fetch(${process.env.NEXT_PUBLIC_API_URL}/settings/, { next: { revalidate: 3600 } }) - then: Failed to set fetch cache

[Tekutorukushi]

no any solutions?

[timomedia]

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?

[osehmathias]

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.

[RossMcMillan92]

Seeing similar too on 13.4.19 and node 18.17.1. Getting a bunch of these errors:

/home/<user>/.nvm/versions/node/v18.17.1/bin/node:  must be 0 or in range 1024 to 65535.

[Alshie]

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

- ready started server on [::]:3000, url: http://localhost:3000

in 13.4.12 and below I get

- ready started server on 0.0.0.0:3000, url: http://localhost:3000

So it seems to be losing the hostname? I am not running a custom server in any way, just standard setup

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.1
      npm: 9.6.7
      Yarn: 1.22.19
      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.1.3
    Next.js Config:
      output: N/A

[peti446]

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'
  }
}

[joey-ma]

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!

[timomedia]

This bug is currently no one cares and fix it? Or is it because this error is sometimes encountered and sometimes not encountered?

[MTaghinia]

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.

[FerrariAndrea]

Using

• next: 13.4.19
• Node: 18.17.0

Similar issues in 2 different forms of logs:

[    ] - info Generating static pages (88/156)Failed to set fetch cache MY_URL_REQUEST TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at async globalThis.fetch (D:\Illuminem\website\node_modules\next\dist\server\lib\patch-fetch.js:93:16)
    at async invokeRequest (D:\Illuminem\website\node_modules\next\dist\server\lib\server-ipc\invoke-request.js:17:12)
    at async invokeIpcMethod (D:\Illuminem\website\node_modules\next\dist\server\lib\server-ipc\request-utils.js:45:21)
    at async D:\Illuminem\website\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'
  }

and

Failed to set fetch cache MY_URL_REQUEST  TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at async globalThis.fetch (\.next\server\chunks\218.js:8461:16)
    at async invokeRequest (\node_modules\next\dist\server\lib\server-ipc\invoke-request.js:17:12)
    at async invokeIpcMethod (\node_modules\next\dist\server\lib\server-ipc\request-utils.js:45:21)
    at async \.next\server\chunks\218.js:8659: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'
  }
}

Resolved downgrading the next.js version to 13.4.12

[Kevin-McGonigle]

Getting similar on Node 18.17.1 and Next 13.4.19 when running dd-trace in a startup script:

TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at async invokeRequest (/app/node_modules/next/dist/server/lib/server-ipc/invoke-request.js:17:12)
    at async invokeRender (/app/node_modules/next/dist/server/lib/router-server.js:254:29)
    at async handleRequest (/app/node_modules/next/dist/server/lib/router-server.js:447:24)
    at async requestHandler (/app/node_modules/next/dist/server/lib/router-server.js:464:13)
    at async /app/node_modules/dd-trace/packages/datadog-instrumentations/src/next.js:157:22
    at async Server.<anonymous> (/app/node_modules/next/dist/server/lib/start-server.js:117:13) {
  cause: SocketError: other side closed
      at Socket.onSocketEnd (node:internal/deps/undici/undici:9790:26)
      at Socket.emit (node:events:526:35)
      at Socket.emit (/app/node_modules/dd-trace/packages/datadog-instrumentations/src/net.js:61:25)
      at endReadableNT (node:internal/streams/readable:1359:12)
      at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
    code: 'UND_ERR_SOCKET',
    socket: {
      localAddress: redacted,
      localPort: redacted,
      remoteAddress: undefined,
      remotePort: undefined,
      remoteFamily: undefined,
      timeout: undefined,
      bytesWritten: redacted,
      bytesRead: redacted
    }
  }
}

[diaz-hfc]

Having this issue on 13.5.1. :(

[Arctomachine]

Encountering it on latest, node version is 20.2.0. So node version seems to be irrelevant in this issue. One project errors, it has rather big fetches (about 100kb). Another project not, it has tiny fetches.

[diaz-hfc]

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

[Tekutorukushi]

This error is present on Windows. On the Ubuntu server, the build occurs without errors next 13.5.1

[FerrariAndrea]

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.

[timomedia]

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

[diaz-hfc]

For me probably it is big payloads entering into the cache or something like that.

[jwalcher]

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.

[diaz-hfc]

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.

[BarrySaikSoundry]

I had this error hosting on AWS amplify - upgrading to the node build image to public.ecr.aws/docker/library/node:20.5.1 fixed it.

[ShahriarKh]

I also face this error when the response of graphql is large. Both on Windows and linux (node 16). The only solution I've found so far is to use cache: no-store, but this means no caching, and that's not what I'm looking for.

[FerrariAndrea]

Tested on next.js 13.5.3. Error still here.

[diaz-hfc]

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.

[FerrariAndrea]

Make sense, that is why the 13.4.12 is working, the code is drastically different. The request-utils don't exist, and the Invoke seems to handle the Post method too: https://github.com/vercel/next.js/blob/552bca46eb5779d238a140e70aa5ec03355098ee/packages/next/src/server/lib/server-ipc/invoke-request.ts#L30

(I'm not sure that is really related because is not clear to me what is happening in that code)

[franky47]

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.

[FerrariAndrea]

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 problem is how it is possible that they are using only the GET request instead of POST which has these limitations.

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.

[diaz-hfc]

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

[Arctomachine]

How exactly does this error impact production server? Does it disable cache for errored route and force new requests for every page visit?

[diaz-hfc]

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

[Arctomachine]

I tested different canary versions of 13.4.13, this error starts between canary 3 and 4: https://github.com/vercel/next.js/compare/v13.4.13-canary.3...v13.4.13-canary.4 Prior to canary 4 there was different error. And exclusively at canary 16 build fails completely.

Canary <4, error -4094

[Error: UNKNOWN: unknown error, open '<path to project>\.next\cache\fetch-cache\<some file name>'] {
  errno: -4094,
  code: 'UNKNOWN',
  syscall: 'open',
  path: '<path to project with double backslashes>\\.next\\cache\\fetch-cache\\<some file name>'
}

Canary 4+, error -4077

TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11522:11) {
  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'
  }
}

Canary 16 only

TypeError: e.startsWith is not a function

[Arctomachine]

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)

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:313:12)
    at TCP.callbackTrampoline (node:internal/async_hooks:130: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:313:12)
      at TCP.callbackTrampoline (node:internal/async_hooks:130:17) {
    code: 'UND_ERR_SOCKET',
    socket: {
      localAddress: undefined,
      localPort: undefined,
      remoteAddress: undefined,
      remotePort: undefined,
      remoteFamily: undefined,
      timeout: undefined,
      bytesWritten: 26932,
      bytesRead: 67
    }
  }

[diaz-hfc]

@Arctomachine for me I first see "failed to set fetch cache", then following the one you are showing.

[geryit]

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

[Arctomachine]

I think I might have encountered the longer error in different scenario too. At least it had similar syntax. It happened when I enabled support for avif images. Initial build was successful, but as soon as I opened site and tried to navigate, images took very long time to appear and console thrown bunch of similar errors. During that time processor load was constantly at 100%. So can it be related to current issue? Can this error too happen because next is requiring more computing power than hardware can provide during certain steps?