Couldn't connect on 127.0.0.1:6000 with VSCode 1.82.0

[DigiEggz]

Couldn't connect on 127.0.0.1:6000 with VSCode 1.82.0

[giuppe]

A workaround is to explicitly launch
haxe -v --wait 6000
in a vscode terminal.

[Soup-Wizard]

Seriously, THANK YOU ALL. I just started trying Haxe/Heaps last night and couldn't even get the Hello World file for heaps to compile. Reverting VS Code versions worked.

[AlexHaxe]

haxe --wait 127.0.0.1:6000
Fatal error: exception Failure("Couldn't wait on 127.0.0.1:6000")

you have some process already occupying port 6000. you can only have one combination of host and port open on a single system.

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost

try ping localhost, it's probably pinging ::1.

[AlexHaxe]

vshaxe version 2.30.0 was just released. you should now be able to upgrade to VSCode 1.82.x

[Syopic]

Yes, downgrading to 1.81.1 solves the problem

[kLabz]

@AlexHaxe Does haxe --wait 127.0.0.1:6000 + haxe --connect 127.0.0.1:6000 work on such a windows machine using ::1 as localhost?

If so, proposed plan:

• Add some kind of "haxe server host" config to vshaxe + haxe lsp, with 127.0.0.1 as default
• Use it explicitly for --wait and --connect
• Update Haxe host+port parsing + socket opening to support ipv6 too for future proofing

[AlexHaxe]

@kLabz seems to be working. I'm going to do some more testing and then we can aim for a new version.

[kLabz]

Anyone reproduces this issue on linux? (or windows btw, could be a mac only issue somehow)

[kisetil]

Hi, I have the same problem on Windows, a few days ago before the VS update everything worked correctly. Regards

[israboy-tech]

Thanks everyone for identifying the root source of the issue, I spent all weekend trying to solve this!

A workaround is to explicitly launch haxe -v --wait 6000 in a vscode terminal.
Doing this will let you compile but I couldn't debug (or even run the application).

Anyone reproduces this issue on linux? (or windows btw, could be a mac only issue somehow)
I can confirm this is something happening on Windows 10 too.

[djaonline]

I've been having the same issue on my linux distro since 1.78 version of vscode. #589

[datee]

I had the same issue too! Had to downgrade VSCode to 1.81 on Windows ... is a fix possible?

[RblSb]

We added better connection error message to nightly, so someone can test it and write what exactly unix error this is (maybe @kLabz can rebuild this commit to make it available on build.haxe.org)
HaxeFoundation/haxe@44c9abd

[AlexHaxe]

after some testing on a Windows machine I found out what causes it and how to reproduce it:
on systems where localhost resolves to ::1 vshaxe will open port 6000 on localhost (== ::1) while haxe --connect 6000 will try to connect to 127.0.0.1 which obviously fails (with No connection could be made because the target machine actively refuxed it.).

so if your hosts file contains the line ::1 localhost then you will likely run into that problem (that's also how you provoke it).

[RblSb]

Can be related to vscode change where v4 ips are not sorted first anymore?
microsoft/vscode#192545

[AlexHaxe]

could be yes.

I guess the solution would be to explicitly set hostname to localhost when running tasks via compilation server (so tasks and Haxe server use the same name).

[RblSb]

Hm, why not replace "localhost" with "127.0.0.1" instead, in vshaxe and lsp?

[AlexHaxe]

Haxe compiler defaults to 127.0.0.1 when no host is given, so maybe we just change haxe-languageserver to a fixed ip address instead of localhost.

[kLabz]

I'd think using localhost everywhere is a better idea.

It is also important to note you cannot always use 127.0.0.1 for loopback. IPv6 only systems do not respond to such requests since their localhost is linked to the address : :1.

Another significant difference between localhost and 127.0.0.1 is how the request is sent. The request does not go through the network card when pinging the loopback address with the localhost. On the other hand, running 127.0.0.1 does pass through the network card, which may be affected by firewall settings and configurations.

Plus other things like people actually wanting to use some other IP for localhost, etc

[AlexHaxe]

well, localhost somehow doesn't seem to work. not even on console.

on Windows I can telnet ::1 6000 and get Haxe output, but haxe --connect localhost:6000 doesn't seem to connect (and obviously haxe --connect [::1]:6000 doesn't work, because Haxe uses split on : to separate host and port).

on Linux localhost doesn't work even though it resolves to 127.0.0.1. using haxe --connect 127.0.0.1:6000 works however (as does --connect 6000). telnet localhost 6000 successfully connects.

comparing haxe --connect localhost:6000 with haxe --connect 6000 and haxe --connect 127.0.0.1:6000 on Windows shows that localhost produces

Fatal error: exception Failure("Couldn't connect on localhost:6000")

whereas the other two show

Fatal error: exception Failure("Couldn't connect on 127.0.0.1:6000 (No connection could be made because the target machine actively refused it.\r\n)")

tested with haxe_20230908125023_536c388_bin.zip from build artifacts (win64 binaries)

not sure what to make of it.

looking at Haxe source code, I believe it only supports IPv4 sockets for --connect so anything IPv6 cannot work without modifying Haxe first. basically ruling out anything using a hostname for connections, because a hostname can have an A and an AAAA record in DNS and Haxe wouldn't know which one to choose (and would have to try both IPv6 and IPv4 connections).

[Simn]

I'm happy to add IPv6 support to Haxe for this, but that doesn't really help us with the current problem because existing versions have to function anyway...

[kLabz]

I'm checking for ipv6 support in Haxe atm and it seems pretty straightforward
Not sure if there's a nice fix on vshaxe/haxe lsp side only that would cover all these :/

[datee]

this does not work for me (windows 10/11)

haxe --wait 127.0.0.1:6000
Fatal error: exception Failure("Couldn't wait on 127.0.0.1:6000")

in my hosts file:

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost

Meaning its commented out, right...?

[hoseyjoe]

vscode hashlink debugger stopped working around same time for me. Is this potentially the same fix?

[kLabz]

Seems likely indeed