Weather Widget - TRPCClientError: fetch failed
I am having the exact same behavior at https://discord.com/channels/972958686051962910/1329939764094308525, but I am already at 1.20.0 the same issue still persist.
The widget never works since installation for like 99% of the time, it successfully fetched weather info for around 30 minutes after I changed the pi-hole integration from IP address to a local hostname. And then it starts failing again and never worked since.
Here is a list of things I tried:
1. Disabling pi-hole doesn't help, the query logs shows successful resolution to api.open-meteo.com
2. Fetching the URL within the container gives me HTTP 200 with an empty body, no connection errors.
3. Rebooting or restarting the homarr container doesn't help
Solution:Jump to solution
Turns out it's Node's implementation of Happy Eyeballs (RFC 6555) is messing up normally working connections during a race between ipv4 and ipv6.
Adding the following env var removes the issue:
```
NODE_OPTIONS=--network-family-autoselection-attempt-timeout=500...
14 Replies
Thank you for submitting a support request.
Depending on the volume of requests, our team should get in contact with you shortly.
⚠️ Please include the following details in your post or we may reject your request without further comment: - Log (See https://homarr.dev/docs/community/faq#how-do-i-open-the-console--log) - Operating system (Unraid, TrueNAS, Ubuntu, ...) - Exact Homarr version (eg. 0.15.0, not latest) - Configuration (eg. docker-compose, screenshot or similar. Use ``your-text`` to format) - Other relevant information (eg. your devices, your browser, ...)
Frequently Asked Questions | Homarr documentation
Can I install Homarr on a Raspberry Pi?
This is one of the failling logs:
ETIMEDOUT indicates that there is something in between like a proxy that Homarr is not using (but curl / wget maybe does?)
I have a Wifi router and nothing else, the only thing being router's DNS points back to this node's Pi Hole. It should really be the same.
How should I grab the relevant network info the tRPC server sees?
Okay then I don't have a clue why this could happen...
Just tried fetching from the node environment, the ETIMEOUT is almost instantaneous. 🤔
Turns out it's because undici prefers IPv6, confirmed using
curl --ipv6 in container's shell.
But I don't know how to enable IPv6 in the container 😦Can you try setting
NODE_OPTIONS="--dns-result-order=ipv4first" as env variable?Interestingly this env var seems to do nothing, running
node --dns-result-order=ipv4first inside the container also produce failing fetches.Hmm okay, was worth a try
Breaking down the error causes reveals that
ETIMEOUT is specifically about the IPv4 connection, because the error message with IPv6 is ENETUNREACH.
It's only node's fetch fails at this point,
1. ❌ node's fetch fails
2. ✅ deno's fetch works
3. ✅ bun's fetch works
4. ✅ curl -4 works
The same behavior is observed in all 3 environments:
1. homarr's alpine container
2. Raspberry Pi OS
3. macOSSolution
Turns out it's Node's implementation of Happy Eyeballs (RFC 6555) is messing up normally working connections during a race between ipv4 and ipv6.
Adding the following env var removes the issue:
I have no way to tell if 500ms is a good value in general for DNS latencies being variable, and I genuinely think Node.js really messed things up at this specific number.
Interessting...
More context about the short default of 250ms here: https://github.com/nodejs/node/issues/54359
While the contributor is strongly arguing for this value, there is quite a large number of users seeked help after said implementation last year.
So yeah, I'm not sure how well they think they understand their own community.
GitHub
Happy eyeballs implementation times out prematurely · Issue #54359...
Version v20.12.2 Platform Linux 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux Subsystem No response What steps will reproduce the bug? In an IPv4-only environment: NODE_DEB...