search

jeffbski / wait-on

wait-on is a cross-platform command line utility and Node.js API which will wait for files, ports, sockets, and http(s) resources to become available
MIT License
1.87k stars 77 forks source link

Waiting on tcp ports doesn't work in Node 18 #133

Open paulsmithkc opened 1 year ago

paulsmithkc commented 1 year ago

We ran into an issue with Node 18, were wait-on would wait indefinitely for a service to start, even though it was already started.

Environment:

Test Script:

concurrently -k -s first \"wait-on tcp:7071 --timeout=60000 && jest --forceExit\" \"azurite\" \"func start\"

Bitbucket Pipeline:

image: node:18

pipelines:
  default:
    - step:
        name: Test
        caches:
          - node
        script:
          - npm install
          - npm i --location=global azure-functions-core-tools@4
          - npm i --location=global azurite@latest
          - export FUNCTIONS_WORKER_RUNTIME="node"
          - export APPINSIGHTS_INSTRUMENTATIONKEY=""
          - export AzureWebJobsStorage="UseDevelopmentStorage=true"
          - npm run test

We ended up downgrading the Bitbucket Pipeline to Node 16, to make it work for now.

PilotConway commented 1 year ago

I just ran into this as well on my local machine. Running node 18 on a M1 Macbook Pro. Downgrading to 16 also worked to get around it.

metcoder95 commented 1 year ago

Did tried using explicitly 127.0.0.1?

BrunoBernardino commented 1 year ago

I just ran into this as well, on M1 Macbook Air, and GitHub actions CI on Ubuntu 20.04 (but not on my local Linux machine, running a variant of Ubuntu 22.04).

Using tcp:127.0.0.1:PORT did work, but not http://localhost:PORT nor tcp:localhost:PORT, so it seems related to localhost and not the protocol.

BrunoBernardino commented 1 year ago

So, turns out that's not exactly the issue. wait-on seems to be working fine, and I can get tcp:localhost:PORT to work, as long as that program is listening on ipv6. This is because Node changed the ipv4 preference to ipv6 from 17+.

The solution is to make those apps listen in ipv6 or wait for them on 127.0.0.1 instead (explicit ipv4).

Reference links:

Have fun digging into those!

Lazerbeak12345 commented 3 months ago

I noticed that with the -v flag, it always has file: in front of whatever I told it to await, such as a tcp port. If this isn't related, it perhaps merits another bug, but that's how I got here anyway. Is this the same bug?

Edit: the problem was that my host shell didn't know how to handle CRLFs (DOS). fixed by switching to just LFs (UNIX).

TLDR: not related to this issue.