wait-on "localhost" not resolving after upgrading Node.js 16 to 18

[casewalker]

My project is upgrading from Node 16.14.2 to 18.12.1.

On my local machine using Chrome, going to our homepage (on port 8000) using the "localhost" name works without issue (http://localhost:8000/).

In our Github workflow, we have:

name: CI
on: [push]
env:
  [...]
  NODE_VERSION: 18

jobs:
  [...]
  e2e-test:
    timeout-minutes: 20
    runs-on: ubuntu-latest

    steps:
      - run: echo $HOME
      - name: Check out the code
        uses: actions/checkout@v3

      - name: Use node ${{ env.NODE_VERSION }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'yarn'

      - name: Cypress run
        uses: cypress-io/github-action@v4
        with:
          start: yarn develop
          browser: chrome
          wait-on: "http://localhost:8000/"
          wait-on-timeout: 300
          command-prefix: 'percy exec -- yarn'
      [...]

However, this wait-on ends up timing out, resulting in the error:

...
You can now view [website] in the browser.
⠀
  http://localhost:8000/
⠀
View GraphiQL, an in-browser IDE, to explore your site's data and schema
⠀
  http://localhost:8000/___graphql
⠀
...
success Building development bundle - 97.705s
success Writing page-data.json files to public directory - 0.791s - 257/257 324.90/s
http://localhost:8000/ timed out on retry 331 of 11, elapsed 330780ms, limit 330000ms
Error: connect ECONNREFUSED 127.0.0.1:8000

This was working on Node 16 but now breaks on Node 18.

Doing some digging, I came across this discussion in the Node repository, saying that starting with Node 17, the IPv4 address "127.0.0.1" would no longer be accepted by default.

But when I changed my Github config above to use wait-on: "http://[::1]:8000/" instead of localhost, the error went away.
This leads me to believe that wait-on is not being "smart" about localhost.

Please let me know if this is an issue on my side that I should change or if you agree this is something to be tackled on the Cypress side.

[plasek100]

I have the same problem since few days, but I did not change anything in my project. 10 days ago Cypress works fine on my github actions, since yesterday it stared giving error like above. I don't know what is the problem.

[plasek100]

In my case problem was solved by updating Node.js from 16.11 to 16.13 and cypress 9.4 to 9.7.

[mraible]

I experienced this today. Changing my GitHub Actions workflow to use Node 16 (from 18) solved the problem. For Node 18, I had to use wait-on: 'http://[::1]:4200' for it to work. This value does not work with Node 16. So I ended up with this:

name: Demo CI

on: [push, pull_request]

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16, 18]
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Use Node ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
      - name: Install latest Chrome
        run: |
          sudo apt update
          sudo apt --only-upgrade install google-chrome-stable
          google-chrome --version
      - name: Install dependencies
        run: npm ci
      - name: Run unit tests
        run: xvfb-run npm test -- --watch=false
      - name: Run integration tests
        uses: cypress-io/github-action@v5
        with:
          start: npm start
          install: false
          wait-on: ${{ matrix.node-version == 18 && 'http://[::1]:4200' || 'http://localhost:4200' }}

[MikeMcC399]

@mraible

I couldn't reproduce this using .github/workflows/example-wait-on.yml and Node.js 18.

• Which server is npm start starting in your configuration?

[mraible]

It's running ng serve from an Angular app created with the Angular CLI.

[MikeMcC399]

@mraible

It's running ng serve from an Angular app created with the Angular CLI.

Thanks for the additional information. I was able to reproduce this issue.

[MikeMcC399]

@casewalker

Which server are you starting with yarn develop?

[MikeMcC399]

@mraible

• I've added a new issue wait-on failure ECONNREFUSED to localhost with Angular and Node.js 18 #760 to be clearer about how to reproduce it. I wasn't able to find a solution. I just found an additional workaround of using a different server.
• I noticed that other servers will respond to both IPv4 127.0.0.1 and IPv6 ::1 whereas ng serve seems to respond to one or the other, but not both. The ideal situation would be for Angular and Cypress development engineers to look at this together.

[MikeMcC399]

@mraible

There is another alternative which I previously overlooked. It is documented in README: Wait-on.

Use the npm package wait-on to wait for the Angular server ng serve to come online.

Execute:

npm install wait-on

and replace

wait-on: 'http://localhost:4200'

with a 60 second wait for the server using wait-on

wait-on: 'npx wait-on --timeout 60000 http://localhost:4200'

The npm package wait-on behaves differently to the built-in wait-in, which is based on the npm package got, so this may be a useful workaround in other situations as well.

[nagychris]

@mraible

There is another alternative which I previously overlooked. It is documented in README: Wait-on.

Use the npm package wait-on to wait for the Angular server ng serve to come online.

Execute:

npm install wait-on

and replace

wait-on: 'http://localhost:4200'

with a 60 second wait for the server using wait-on

wait-on: 'npx wait-on --timeout 60000 http://localhost:4200'

The npm package wait-on behaves differently to the built-in wait-in, which is based on the npm package got, so this may be a useful workaround in other situations as well.

Thanks, for me this was the solution. I was using a custom start command with pnpm and vite preview --port 8080, which also produced the ERRCONNREFUSED error in the CI - whereas locally the dev server started and was reachable.

[MikeMcC399]

• GitHub has now switched the default Node.js version to 18 in GitHub hosted runners, so I expect that more related issues are going to start surfacing. This includes one set of examples here in the repository. See issue example-wait-on fails on GitHub waiting for localhost #802.

Edit: The examples are now fixed, in the sense that a workaround has been implemented. See PR #803.

[MikeMcC399]

@casewalker

It would be great to know which dev webserver you were using when you wrote that you had an error message
Error: connect ECONNREFUSED 127.0.0.1:8000
and you worked around the issue by using
wait-on: "http://[::1]:8000/"

Perhaps you could let us know? I am trying to compile a list of workarounds for this issue.

[casewalker]

Hey @MikeMcC399, on the project where I found this we were using GatsbyJS v5 and starting a server with gatsby develop and no other arguments (no host or port overrides, no HTTPS or anything):

https://www.gatsbyjs.com/docs/reference/gatsby-cli/#develop

[MikeMcC399]

Hi @casewalker

• Many thanks for providing the information that your problem was with Gatsby! That filled in the information gap. I used the Quick Start Guide to set up Gatsby version: 5.7.0. It uses a react web server which has been causing similar issues elsewhere. The problem is that it does not listen on both IPv4 and IPv6. If you start it with the default npx gatsby develop it listens on IPv6 ::1, not on IPv4. If you start it with npx gatsby develop -H 0.0.0.0 it listens on IPv4 127.0.0.1, not on IPv6. Gatsby 5 requires a minimum of Node.js 18, so I couldn't test how it works with Node.js 16 and I didn't try with Gatsby 4.

Please let me know if this is an issue on my side that I should change or if you agree this is something to be tackled on the Cypress side.

• You already found the best workaround which is wait-on: http://[::1]:8000. It's the same workaround as for Angular (see wait-on issues with Node.js 18 #811 (comment)).

• I also found that I could start the "getting started" version of Gatsby and test it with Cypress without using wait-on at all.

• I opened a general issue wait-on issues with Node.js 18 #811 to raise the question in more detail about whether cypress-io/github-action needs to be changed to cope with dev webservers running on Node.js 18 and later which do not listen on both IPv4 and IPv6 stacks. (I don't mention Node.js 17 any more. Although this is the version which introduced the breaking change which you identified, it already entered end-of-life on June 1, 2022, so it doesn't need to be supported as such any longer.)

[MikeMcC399]

There are now generic workaround instructions posted to wait-on with Node.js 18+ concerning this issue.

[casewalker]

@MikeMcC399 Thank you very much for all of this relevant information and the related tickets. As far as I can tell, you have done everything that should be done to close this ticket. I have not closed it myself because I don't think I know enough context to be that judge here, and I am no longer on the project I was on when I opened this (and I'm not using Gatsby anymore either).

But please feel free to close it, it seems to me like you have provided all of the relevant and necessary context to help someone who ends up here either solve their issues or know where to look outside of Cypress for persisting issues.

[MikeMcC399]

@casewalker

Thank you for your assessment! I don't think that it is necessary to keep this issue open any more. I don't however have privileges to close other users' issues myself, since I am only an external contributor. So, I would suggest that you yourself click on the Close button. It may take a while for the Cypress.io team to catch up.

[ThibDums]

Since Node v17.0.0, you have to use the following node option on your pipeline (for me, bitbucket pipeline does not allow ipv6 adresses)

export NODE_OPTIONS=--dns-result-order=ipv4first

[MikeMcC399]

@ThibDums

Thanks for your tip! Which web server are you testing on? I'm not sure that the environment variable will solve the issue for all dev webservers.

In the meantime some other workaround suggestions have been posted to wait-on with Node.js 18+

• There is another (open) issue on this topic wait-on issues with Node.js 18 #811.