S32-io/IO-Socket-Async.t incorrectly fails when IPv6 is disabled on a host about roast

[Kaiepi]

This will be fixable with my solution for https://github.com/Raku/problem-solving/111. PR will be up soon-ish.

[Kaiepi]

Roast currently assumes that both IPv4 and IPv6 loopback interfaces exist, which is not ideal. If we had a way of working with networking interfaces, then we could determine whether or not any 127.0.0.1 or ::1 addresses exist before attempting to use them. I'm not sure how else you could determine if IPv6 is supported or not by a system without winding up with false positives from issues with DNS resolution or sockets themselves as things currently stand.

With the solution for Raku/problem-solving#111 I'm working on, there would exist resolver interfaces. Whether or not IPv6 addresses can be resolved when it isn't supported by a system is backend-dependent behaviour though.

[vrurg]

I hope that backend-specific issues we'd be able to resolve using conditionals. Otherwise you confirm the conclusions I made after investigating the matter.

Looking forward for your success on the problems-solving issue!

[niner]

I wonder how much of an issue this is? Systems without v6 should become rarer and rarer. How many of those will want to run roast? OTOH this has been reported, so it is at least one... -- Stefan

[AlexDaniel]

I wonder how much of an issue this is? Systems without v6 should become rarer and rarer. How many of those will want to run roast? OTOH this has been reported, so it is at least one...

Actually pretty common. There were at least two different occasions in the last few years I had to disable ipv6 on my machines because things were misbehaving. I have little reason to change it back given that the connection I have doesn't support ipv6 anyway. Although, the test is passing for me so I guess I reinstalled the system during that time, so locally it is enabled again.