-
Notifications
You must be signed in to change notification settings - Fork 540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeError: fetch failed - on Node v20.11.1 and v21.7.1, but works on v18.19.1 - likely issue with resolving redirect URL or IPv6 #2990
Comments
I can't reproduce unfortunately :(. Is there a proxy configured? |
@mcollina thank you for looking into to that! There is no proxy configured. Today I cannot replicate the error as well. The only thing that has changed in between (that I can think of) is that I have updated NVM. I have also tried in a few ways on a different machine - I am not able to replicate it again. In this case should I close the issue? |
Yes, thanks for reporting |
may I know what version of node you are using? |
@RealYukiSan However a week later , there was no more error. Ether it was related to me updating NVM ( cant say why) or maybe this was related to DNS setup of target URL... can' really tell. |
@mcollina @RealYukiSan I believe I have found the root cause of the most of ETIMOUT across most of the issues. TLDR What solved the issue completely for me was increasing that timeout to: Likely explanation This error was popping up for me only on Airtable API and only via node fetch/undici, no problem with other APIs, no problem with cURL accessing the same API. It hard to replicate - because day a few days after original issue started it went away by itself. Same situation with builds no vercel. Likely on some days 250ms is enough on other days with more traffic it was not enough Here is a screenshot of connecting with Some of the solutions suggested on other threads/issues which suggested turning off the ipv6 or using Google /CF DNS (8.8.8.8 1.1.1.1) might have helped by the virtue of allowing for a faster connection which managed under 250 ms but on some networks (e.g. located physically on the other side of the globe ) - this timeout is too short. I was not able to find any parameter in undici that controls this timeout so I have modified it directly via Node options in bash command You might also want to add this directly in package.json: This results in longer timeout visible in DEBUG logs and successful connections: Networks layers are a bit over my head, this seams like a reasonable explanation of what is going on, but it would be great if someone could verify this reasoning. I can't also really tell what could be the side effects of longer timeout on production scale applications. I hope this is helpful, as it took me crazy amount trying to solve this. |
@mcollina @RealYukiSan I believe I have found the root cause of the most of ETIMOUT across most of the issues. TLDR What solved the issue completely for me was increasing that timeout to: Likely explanation This error was popping up for me only on Airtable API and only via node fetch/undici, no problem with other APIs, no problem with cURL accessing the same API. It hard to replicate - because day a few days after original issue started it went away by itself. Same situation with builds no vercel. Likely on some days 250ms is enough on other days with more traffic it was not enough Here is a screenshot of connecting with Some of the solutions suggested on other threads/issues which suggested turning off the ipv6 or using Google /CF DNS (8.8.8.8 1.1.1.1) might have helped by the virtue of allowing for a faster connection which managed under 250 ms but on some networks (e.g. located physically on the other side of the globe ) - this timeout is too short. I was not able to find any parameter in undici that controls this timeout so I have modified it directly via Node options in bash command You might also want to add this directly in package.json: This results in longer timeout visible in DEBUG logs and successful connections: Networks layers are a bit over my head, this seams like a reasonable explanation of what is going on, but it would be great if someone could verify this reasoning. I can't also really tell what could be the side effects of longer timeout on production scale applications. I hope this is helpful, as it took me crazy amount trying to solve this. |
Can you send a PR to add the above to https://github.com/nodejs/undici/tree/main/docs/docs/best-practices? I think it would be valuable for others. Note that you should be able to customize this at Agent creation time via https://nodejs.org/api/net.html https://github.com/nodejs/undici/blob/main/docs/docs/api/Client.md#parameter-connectoptions |
Bug Description
Making
fetch
request fails with TypeError and array of errors.Originally this error showed up by breaking my NextJS project, when upgrading to Next v14. Digging through NextJS issues relating to TypeError: fetch failed I found out that this was relating to
undici
Reproducible By
Executing below in command line (on Node v20.11.1 and v21.7.1)
node -e "fetch('https://airtable.com').then(res => console.log(res.status))"
will result in TypeError: fetch failed
Expected Behavior
Expected result is 200. For comparison:
curl -s -o /dev/null -w "%{http_code}\n" https://airtable.com/
will result in 301
node -e "fetch('https://airtable.com').then(res => console.log(res.status))"
will result in 200
node -e "fetch('https://www.airtable.com').then(res => console.log(res.status))"
will result in 200
Originally I was accessing Airtable API, but I was able to reproduce the error just on the homepage.
Logs & Screenshots
At the same time there is no issue in reaching that URL with cURL
Environment
Additional context
Windows 10 running WSL 2 with Ubuntu 20.04.6 LTS
The text was updated successfully, but these errors were encountered: