wait-on perpetually returns ECONNREFUSED when using localhost, but works fine using 127.0.0.1

[thepuzzlemaster]

I had been using the start-server-and-test module for kicking off my server, and then starting my tests, however I couldn't get it to work using http. I ended up creating a minimal repro here (note the wait-on-defect branch).

I realized that it does however, work fine if I switch my localhost to 127.0.0.1. I can curl the localhost fine in a terminal window and it returns the html string. I'm using next js as my server, which does run via webpack, so using http-get, but to no avail.

repro steps:

• pull down minimal repro and checkout wait-on-defect branch
• yarn install
• yarn test:integration

[sebastiancarlsson]

+1 on this, I'm using vite's "preview" functionality to run my app. It works if I use 127.0.0.1 instead of localhost.

[nicarl]

We faced the error in https://github.com/opossum-tool/OpossumUI when upgrading to node 17. Replacing localhost by 127.0.0.1 works

[DasSkelett]

Most likely cause is nodejs/node#39987 (see also nodejs/node#40537).
You could update your apps/services to listen on IPv6 as well, or if they're hardcoded to 127.0.0.1, you need to hardcode it for wait-on as well, as already mentioned.

[Saltallica]

+1 still a thing in node 18

[JacobMuchow]

Experienced the same thing. It took me a few hours to track this down. I think it would be useful, if not important, for the project to handle this in some fashion since LTS is 18.12.0 and current Node version is 19.0.0.

Two solutions for me were to:

• Downgrade to node 16 (16.18.0)
• Use http://127.0.0.1:3000 instead of tcp:3000 or http://localhost:3000

[metcoder95]

Hey! This is not an issue from the library itself, but from this change previously mentioned: node#39987. As some times and depending on the OS is possible that it will return an ipv6 instead of ipv4, which on some machines the localhost host doesn't resolve to ipv6. Until the HappyEyeballs implementation is merged in Node, this will still be a problem if your host's config within your machine is set to resolve first the ipv6 over ipv4 and the service/tool doesn't listen to both IP versions.

The recommendation is to be careful and try to listen to verify if the tool/service listens to both IP versions, and if note, point directly to the one that is resolved first on your host config.

[sun0day]

localhost resolve behavior changed since node17. See nodejs/node#40702

[metcoder95]

Hi guys! It seems that sadly the project hasn't been active lately, and issues are just pilling up 🙁
In an effort to continue using the project, and of course, with all the respect to @jeffbski, I take my time to do a fork of the project, make improvements and fix some of the issues noted here and other issues within this project.

The effort is not to replace this great project but try to continue adding support to it in parallel. Hopefully, you'll find it helpful 🙂

It is important to notice that I made some refactors and improvements, for instance, the current version is 0.1.0, meaning that is possible to have slightly breaking changes within the current version before jumping into the first stable one 🙂

Hope you found it useful and am happy to help you through the issues section of the project. Looking forward to your feedback!

Link: https://github.com/metcoder95/wait-on

[lrNas]

Hello folks! It seems that in v18.12.1 the same is happening.

[metcoder95]

It happens because the happy eyeballs option is not enabled by default 🙁