Auth won't retry over IPv4 when IPv6 connection fails

[PseudoResonance]

• The readme doesn't contain a resolution to my issue
• The example doesn't contain a resolution to my issue

Versions

• node: 23
• prismarine-auth: 2.5.1

Detailed description of a problem

If IPv6 connectivity fails and Prismarine-Auth has decided to connect over IPv6, it will just wait for a long time before timing out instead of retrying over IPv4.

Your current code

const botSettings = {
	version: '1.12.2',
	auth: 'microsoft',
	username: 'username',
	profilesFolder: 'profiles'
};
mineflayer.createBot(botSettings);

Expected behavior

I expect Prismarine-Auth to timeout the connection faster by default, then if the other IP version also seems available, retry using it. Ex: Retry with IPv4 if IPv6 times out, or retry with IPv6 if IPv4 times out.

Additional context

Comcast had a temporary IPv6 outage, so I normally have good IPv6 connectivity, but for about 24 hours I didn't. More often than not, when I ran Mineflayer, it would try to authenticate over IPv6 and wouldn't be able to connect.

I'm not sure if this is normal for Minecraft, but this behavior of automatically retrying over the other IP version is standard when a browser visits a webpage and finds it can't connect. I doubt it needs to be anything particularly fancy. Perhaps it could even try to initiate a connection over both IPv4 and IPv6 simultaneously, and just close whichever one opened slower. I believe this is similar to how browsers handle it.

---

[extremeheat]

Prismarine-auth doesn't have that level of control. We use node-fetch or the Node.js built in fetch function that abstracts the network logic away. There is no way to know therefore it was a IP protocol version error or to switch the stack in fetch.

Node18 seems to use IPv6 by default now when available. What you are probably looking for is this nodejs flag to revert the behavior with --dns-result-order.

https://nodejs.org/docs/latest-v19.x/api/cli.html#--dns-result-orderorder

node --dns-result-order=ipv4first app.js

[PseudoResonance]

It's not just IPv4 vs IPv6 first though. This makes one attempt and never retries. Surely there's something that can be done within the confines of node-fetch... I will try looking myself too.

Nevermind, I immediately found it this time.

node-fetch/node-fetch#1297

This comment apparently can use happy eyeballs with node-fetch though.

[extremeheat]

The node-fetch dep is from before Nodejs had a built in fetch function, which we will probably be remove in future. I don't think it makes sense to patch here as you would have to apply the same patches here for all calls in all other packages. I recommend making an issue in nodejs if there's something you can reproduce there where it's not using IPv4.

[extremeheat]

Possible that #118 will fix issues on its own

[PseudoResonance]

I believe Node 18 added happy eyeballs support, so theoretically Node 21's new native fetch should already support it. If you're going to be replacing node-fetch with the native fetch, then I'm pretty sure it will fix this issue. I just wasn't sure if you wanted to limit the Node version to >=21.

[extremeheat]

fetch was added to Node.js in v18. The PrismarineJS projects are pretty much all require node=>18, and our CI here is currently testing against 20. So there is no issue there.