Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Happy Eyeballs

See original GitHub issue

Is your feature request related to a problem? Please describe.

DNS misconfigurations or server down time can cause fetch requests not to be fulfilled. In the browser, this is handled for you using the Happy Eyeballs algorithm.

This functionality is also implemented in curl, iOS, Android, etc…

With IPv6-only network connectivity becoming increasingly common, misconfigurations in DNS servers can cause requests to fail, even when connectivity is available through alternative servers.

Browsers typically try to create a connection, wait 300ms, then try the next available server provided by getaddrinfo in the kernel.

Currently, node-fetch implements no failover for support for timed-out connections.

Describe the solution you’d like

I would propose node-fetch handle failover similarly to the browser. Or better yet, curl’s implementation.

net.createConnection attempts to create a connection with the default dns.lookup server. Btw, semi-related, the DNS lookup should be returning results with verbatim=true. Currently, due to a poor design decision by NodeJS developers, IPv4 addresses are preferred, even when this contradicts RFC 6724. Note, that verbatim=true will probably become the default.

This can cause extremely confusing errors for developers using dual stack networks where IPv4 support periodically drops, because it’s very hard to find what is causing the issue (I should know).

Ideally, fetch would send the first address first, wait 300ms, and if no connection was made, continue down the line of addresses returned by dns.lookup.

It could be a good idea to log a warning for the user that the first address sent by getaddrinfo was not available, as the 300ms timeout adds latency to every connection.

Still, this is better than dropping the request entirely.

In curl’s implementation, which I prefer, its starts with the first address, then tries the next address of a different family.

So, if you’re on a IPv6-only network, you don’t have to try every single IPv4 address before you get to the IPv6 address.

Describe alternatives you’ve considered

It would be great if node could implement this natively, but there are currently no plans to do that.

Ultimately though, I think it would probably be better for the community to develop something like this and test it out before merging it into NodeJS anyway and see the response it gets. If it’s extremely popular, NodeJS can merge it in, and the code can be removed from here.