undici: TypeError: fetch failed

Maybe this can help?

I am experiencing the same with a Firebase Emulators host.

$ git clone https://github.com/akauppi/firebase-jest-testing.git
$ cd firebase-jest-testing

$ git checkout 0d2a5f43022453a34a3de9510f9e436b4d890078    # reproducible in this commit

$ npm install

In one terminal:

$ npm run start

In another:

$ npm run test:fns:greet
...
(node:37466) ExperimentalWarning: VM Modules is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
 FAIL  sample/test-fns/greet.test.js
  Cloud Function callables
    ✕ returns a greeting (15 ms)

  ● Cloud Function callables › returns a greeting

    TypeError: fetch failed

      at Object.processResponse (../../node_modules/undici/lib/fetch/index.js:183:23)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        0.324 s, estimated 1 s
Ran all test suites matching /greet.test.js/i.

---

Added: Once npm run start is running, you can exercise the server by:

$ curl -v -X POST -d '{"data":"abc"}' -H "Content-type: application/json" http://localhost:5002/demo-1/mars-cent
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying ::1:5002...
* connect to ::1 port 5002 failed: Connection refused
*   Trying 127.0.0.1:5002...
* Connected to localhost (127.0.0.1) port 5002 (#0)
> POST /demo-1/mars-central2/greet HTTP/1.1
> Host: localhost:5002
> User-Agent: curl/7.77.0
> Accept: */*
> Content-type: application/json
> Content-Length: 14
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< x-powered-by: Express
< vary: Origin
< content-type: application/json; charset=utf-8
< content-length: 28
< etag: W/"1c-90pTE8vnJrTHpo49hh2KVRcGoxw"
< date: Sun, 27 Feb 2022 12:33:58 GMT
< connection: close
< 
* Closing connection 0
{"result":"Greetings, abc."} 

---

Trying with 127.0.0.1 instead of localhost puts the problem at rest:

$ EMUL_HOST=127.0.0.1 npm run test:fns:greet

> test:fns:greet
> NODE_OPTIONS=--experimental-vm-modules jest --config sample/test-fns/jest.config.js -f greet.test.js --verbose --all

(node:38224) ExperimentalWarning: VM Modules is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:38224) ExperimentalWarning: buffer.Blob is an experimental feature. This feature could change at any time
 PASS  sample/test-fns/greet.test.js
  Cloud Function callables
    ✓ returns a greeting (33 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.32 s, estimated 1 s
Ran all test suites matching /greet.test.js/i.

As a temporary solution, please try this:

// Workaround from https://stackoverflow.com/a/72416352/599991
const dns = require('node:dns')
dns.setDefaultResultOrder('ipv4first')

Had the same issue, had to switch from node v18 to v16 as a temp workaround.

@ronag I’m still having these errors. Cannot use undici fetch at all. Here is updated trace from Node v18:

TypeError: fetch failed
    at Object.processResponse (/home/ubuntu/server/node_modules/undici/lib/fetch/index.js:200:23)
    at /home/ubuntu/server/node_modules/undici/lib/fetch/index.js:941:38
    at node:internal/process/task_queues:140:7
    at AsyncResource.runInAsyncScope (node:async_hooks:202:9)
    at AsyncResource.runMicrotask (node:internal/process/task_queues:137:8)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    ... 2 lines matching cause stack trace ...
    at process.processTimers (node:internal/timers:507:7) {
  cause: Error: [object Object]
      at makeNetworkError (/home/ubuntu/server/node_modules/undici/lib/fetch/response.js:366:11)
      at httpNetworkFetch (/home/ubuntu/server/node_modules/undici/lib/fetch/index.js:1751:12)
      at processTicksAndRejections (node:internal/process/task_queues:95:5)
      at runNextTicks (node:internal/process/task_queues:64:3)
      at listOnTimeout (node:internal/timers:533:9)
      at process.processTimers (node:internal/timers:507:7)
      at async httpNetworkOrCacheFetch (/home/ubuntu/server/node_modules/undici/lib/fetch/index.js:1440:29)
      at async httpFetch (/home/ubuntu/server/node_modules/undici/lib/fetch/index.js:1028:33)
      at async schemeFetch (/home/ubuntu/server/node_modules/undici/lib/fetch/index.js:888:14)
      at async /home/ubuntu/server/node_modules/undici/lib/fetch/index.js:569:16
      at async mainFetch (/home/ubuntu/server/node_modules/undici/lib/fetch/index.js:553:16) {
    [cause]: undefined
  }
}

@ronag Could you re-open or reply to my emails?

I don’t think this has anything to do with undici per se. Does it work with the normal http client in node?

It works with curl - I am not very versed in using the normal http client, so… don’t know.

Got some more light to why localhost isn’t recognized by fetch.

My /etc/hosts (macOS 12.2.1 Intel):

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost
# Added by Docker Desktop
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section

If I comment out the line ::1 localhost, things work as normal.

Hello, I have been told I should post my example here as well since I might have the same error: https://stackoverflow.com/questions/73599889/fastapi-refuses-connection-on-a-parameterized-endpoint-if-called-sequentially-wi?noredirect=1#comment129970573_73599889 I am using svelte and fastapi and it seems that I can not fetch two endpoints together but only one of them each.

I also get some error, it’s not the same:

"TypeError: fetch failed\n    at Object.processResponse (C:\\Users\\jeyan\\Documents\\boughtwithslowsearch\\node_modules\\undici\\lib\\fetch\\index.js:183:23)\n    at Fetch.fetchFinale (C:\\Users\\jeyan\\Documents\\boughtwithslowsearch\\node_modules\\undici\\lib\\fetch\\index.js:937:17)\n    at Fetch.mainFetch (C:\\Users\\jeyan\\Documents\\boughtwithslowsearch\\node_modules\\undici\\lib\\fetch\\index.js:744:17)\n    at processTicksAndRejections (node:internal/process/task_queues:96:5)"

ok tested this on v20.4.0 I think its fixed for now can’t say for sure

We have this issue with v20.4.0 also

@mcollina Could you please re-open as this started happening again in Node.js 20 with latest fetch and timeout of 5 minutes.

I’m facing the same issue with Next.js and Strapi. In localhost, the Next.js app can’t fetch the API from Strapi. I recently updated Node.js to version 18.15.0.

error - TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11413:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async fetchQuery (webpack-internal:///./src/utils/fetch.ts:18:22)
    at async Promise.all (index 0)
    at async getServerSideProps (webpack-internal:///./src/pages/index.tsx:47:20) {
  cause: Error: connect ECONNREFUSED ::1:1337
      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
    errno: -4078,
    code: 'ECONNREFUSED',
    syscall: 'connect',
    address: '::1',
    port: 1337
  },
  page: '/'
}

So this just started happening out of the blue. Working with firebase functions. From one minute to the next. I didn’t make any changes to my environment nor did i update or install packages between the time it worked and when it stopped. Restarted Firebase functions and it works again…

TypeError: fetch failed
>      at Object.fetch (node:internal/deps/undici/undici:14152:11)
>      at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
>    cause: ConnectTimeoutError: Connect Timeout Error
>        at onConnectTimeout (node:internal/deps/undici/undici:7967:28)
>        at node:internal/deps/undici/undici:7925:50
>        at Immediate._onImmediate (node:internal/deps/undici/undici:7954:37)
>        at process.processImmediate (node:internal/timers:476:21) {
>      code: 'UND_ERR_CONNECT_TIMEOUT'
>    }
>  }
> Node.js v18.14.0

It could be, for example, a network failure. No way to know here.

I don’t think it’s a network failure. On SvelteKit (which is where I got this error), once it happens once it keeps on happening multiple times (even if I restart node) and then just randomly decides to start working again. I also thought it could have been a network issue but everything else worked perfectly…

edit: typo

+1 node v20, simple fetch request, suddenly, no code changes

TypeError: fetch failed at Object.fetch (node:internal/deps/undici/undici:11522:11) { cause: SocketError: other side closed at Socket.onSocketEnd (node:internal/deps/undici/undici:9740:26) at Socket.emit (node:events:523:35) at endReadableNT (node:internal/streams/readable:1367:12) at process.processTicksAndRejections (node:internal/process/task_queues:82:21) { code: 'UND_ERR_SOCKET',

@bnb if that doesn’t solve the problem… I would definitely need a client/server combo that reproduces the problem.

I think I know what the problem is.

In node v17 we switched the default ordering of dns entries to follow what the OS is providing us vs reordering to put ipv4 always first.

I think we should try multiple addresses when dealing with localhost when establishing a new connection.

Wdyt @ronag?

@gigantino We’re you able to resolve this within SvelteKit? I’m facing the same issue trying to access a certain LinkedIn endpoint (others work fine). Exact same behaviour. Randomly works sometimes when I’m not looking.

@0oj I did by switching to Node 18.16.0

It can be, but it is not. Why? Because it happens only with a certain combination of Node / undici. And it doesn’t happen at all with other combinations. Thus it is a Node / undici issue. And we are talking about sampling periods of weeks here.

It is significant, but even more significant is the repro, which no one could produce so far because the issue is intermittent and not easily reproducible. In our case, for example, when it fails, it fails in like 1 request out of 1000. And as soon as we log the request and retry it, it works just fine without producing the error.

@pauldraper You’re right about the cause. But disregarding whether logging includes the cause or not, there is clearly something wrong with various versions of undici / Node.js. Because with some combinations of undici / Node.js versions TypeError: fetch failed doesn’t happen and with some it happens consistently often, whatever the underlying cause is.

Im not sure why but seems the team decided to ignore this bug ?

No one has provide a repro for them to look into

I removed the line ::1 localhost like this comment, things work again in my Nextjs case.

It’s not related to localhost in many cases.