Error because not valid HostIP

[primeapple]

Hello again,
I experienced another issue. As I described in #18 , I used a wrong version which caused sleep interval to not work correctly. After upgrading to the most current version 2.7.1, I now get the exception:

worker     | thread 'main' panicked at 'The host IP should be valid: AddrParseError(())', src/libcore/result.rs:1165:5
worker     | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
worker     | Checking availability of HOSTNAME:PORT

This seems to be weird, considering, it worked before in version 2.2.1. Did you change the api since then? This config gets printed:

worker     | --------------------------------------------------------
worker     |  docker-compose-wait 2.7.1
worker     | ---------------------------
worker     | Starting with configuration:
worker     |  - Hosts to be waiting for: [HOSTNAME:PORT]
worker     |  - Timeout before failure: 180 seconds 
worker     |  - TCP connection timeout before retry: 5 seconds 
worker     |  - Sleeping time before checking for hosts availability: 10 seconds
worker     |  - Sleeping time once all hosts are available: 0 seconds
worker     |  - Sleeping time between retries: 5 seconds
worker     | --------------------------------------------------------
worker     | Waiting 10 seconds before checking for hosts availability
worker     | --------------------------------------------------------

I hope you can help me. The error is probably on my side...

[ufoscout]

@primeapple
you are trying to wait for a host whose name is "HOSTNAME" and the port is "PORT". Which is why the address cannot be parsed correctly.

[primeapple]

Well, HOSTNAME is of course the hostname i use and PORT is the port I use. In reality its something like postgres:5432. Which worked in version 2.2.1, but not in the current version.

[ufoscout]

@primeapple
in your example, port is not a number, so the parse fails. Could you please paste the output of your real input?
In version 2.7.* the tool fails to start if the address is not valid; on the contrary, in previous versions, the tool simply ignored the wrong address.
If you provide me with the real input, I can check if there's a bug.

[samcoenen]

I have the exact same error as @primeapple:

safely_test     | thread 'main' panicked at 'The host IP should be valid: AddrParseError(())', src/libcore/result.rs:1165:5
safely_test     | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

In my docker-compose.yml I have the following (shortened for clarity):

version: '3'

services:
  safely_nats:
    container_name: safely_nats
    image: nats:2.1.2
    restart: always
    networks:
      - microservices

  safely_test:
    container_name: safely_test
    image: safely/test
    restart: always
    environment:
      WAIT_HOSTS: safely_nats:4222
    networks:
      - microservices
    depends_on:
      - safely_nats

networks:
  microservices:

The Dockerfile for safely/test is as follows:

FROM node:12

ADD https://github.com/ufoscout/docker-compose-wait/releases/download/2.7.1/wait /wait
RUN chmod +x /wait

WORKDIR /usr/src/app

COPY ./package.json ./
RUN npm install --production --progress=false

COPY ./dist/main.js ./

CMD /wait && echo "Starting service" && node ./main.js

Both services are connected through the Docker network, this setup should work just fine.

Full error output during docker-compose up:

[...]
Creating safely_nats  ... done
Creating safely_test ... done
[...]
Attaching to [...], safely_nats, safely_test, [...]
[...]
safely_test     | --------------------------------------------------------
safely_test     |  docker-compose-wait 2.7.1
safely_test     | ---------------------------
safely_test     | Starting with configuration:
safely_test     |  - Hosts to be waiting for: [safely_nats:4222]
safely_test     |  - Timeout before failure: 30 seconds 
safely_test     |  - TCP connection timeout before retry: 5 seconds 
safely_test     |  - Sleeping time before checking for hosts availability: 0 seconds
safely_test     |  - Sleeping time once all hosts are available: 0 seconds
safely_test     |  - Sleeping time between retries: 1 seconds
safely_test     | --------------------------------------------------------
safely_test     | Checking availability of safely_nats:4222
safely_nats     | [1] 2020/01/03 08:44:32.400921 [INF] Starting nats-server version 2.1.2
safely_nats     | [1] 2020/01/03 08:44:32.401144 [INF] Git commit [679beda]
safely_test     | thread 'main' panicked at 'The host IP should be valid: AddrParseError(())', src/libcore/result.rs:1165:5
safely_test     | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[...]
safely_nats     | [1] 2020/01/03 08:44:32.402086 [INF] Starting http monitor on 0.0.0.0:8222
safely_nats     | [1] 2020/01/03 08:44:32.402439 [INF] Listening for client connections on 0.0.0.0:4222
safely_nats     | [1] 2020/01/03 08:44:32.402490 [INF] Server id is [...]
safely_nats     | [1] 2020/01/03 08:44:32.402524 [INF] Server is ready
safely_nats     | [1] 2020/01/03 08:44:32.403355 [INF] Listening for route connections on 0.0.0.0:6222

Using the exact same setup and config as above but reverting docker-compose-wait version from 2.7.1 to 2.6.0 solves the problem, thus proving that the network setup does indeed work and that something inside docker-compose-wait might be broken...

[...]
safely_test     | Host safely_nats:4222 is now available!
safely_test     | --------------------------------------------------------
safely_test     | docker-compose-wait - Everything's fine, the application can now start!
safely_test     | --------------------------------------------------------
safely_test     | Starting service
[...]

Sidenote: docker-compose-wait 2.7.0 also has this problem, only 2.6.1 and older seem to work.

[ufoscout]

@primeapple @samcoenen
Could you please try version 2.7.2? It should be fixed now.

[samcoenen]

@ufoscout 2.7.2 has fixed the issue for me.
Let's hope that's also the case for primeapple.

Cheers!

[primeapple]

@samcoenen , thanks a lot for your contribution!

@ufoscout fixed the problem! Thank you, your project is awesome!