Docker-Compose Wait not being respected

[trajano]

I have a compose file that has a few services but I am generally interested in the database and the webapp primarily.

    new DockerComposeContainer(new File("compose-ca1.yml"))
        .withLocalCompose(true)
        .withLogConsumer("ca1", outputFrame -> System.out.print(((OutputFrame) outputFrame).getUtf8String()))
        .withExposedService("devdb", 3306, Wait.forHealthcheck().withStartupTimeout(ofMinutes(2)))
        .withExposedService("ca1", 8443, Wait.forListeningPort().withStartupTimeout(ofMinutes(2)));

On a Docker Machine setup in Windows I notice that the timeout is not being respected, its not even two minutes and the test fails given something like

org.testcontainers.containers.ContainerLaunchException: Aborting attempt to link to container juedehkaec9f_devdb_1 as it is not running
at org.testcontainers.containers.GenericContainer.applyConfiguration(GenericContainer.java:477)

I started traversing through some old bugs and I noticed this https://github.com/testcontainers/testcontainers-java/pull/514/files#r245190284 it may be assuming that we are using the sockets which is not something I am doing on a Docker Machine setup.

Also looking at the code for DockerComposeContainer#start it goes like this

        createServices();
        startAmbassadorContainers();
        waitUntilServiceStarted();

The stack trace noted that it failed on startAmbassadorContainers() which is for socat. However, I think there should be a check to make sure the services are up because my database takes a bit of time to start up I think the socat creation may be failing there.

[trajano]

There is a withStartupAttempt that can be set but it defaults to 1 from what I can tell I can't find a way of setting that specifically for the socat

[bsideup]

Aborting attempt to link to container juedehkaec9f_devdb_1 as it is not running

this seems to be the cause

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

[stale]

This issue has been automatically closed due to inactivity. We apologise if this is still an active problem for you, and would ask you to re-open the issue if this is the case.