LogMessageWaitStrategy does not work for compose based restarting containers

[Mingela]

trafficstars

Hello!

The case is following:

• testcontainers-java 1.14.3
• docker-compose.yml with services A, B, C
• B depends on A
• C depends on B and A
• withLocalCompose(true)

A starts quite quickly, B start takes ~40 seconds While B is unavailable C keeps restarting

• Tried Wait.forLogMessage() for A - works
• Tried Wait.forLogMessage() for B - works
• Tried Wait.forLogMessage() for C - Timed out waiting for log output matching <log>
• Tried Wait.forLogMessage() for both B and C - Timed out waiting for log output matching <log>

Actually I'm interested in waiting for both of the services B and C explicitly, but only C should be valid as well.

Tried all the possible regex stuff (.*log.*, .*log.*\\s, .*log!\\s, .*log.*\n.* etc)

From my impression it seems that log polling breaks for a restarting container. The difference between B and C here is that when starting B does not encounter broken B->A interaction since A could easily be started for the time of starting B. Hence B does not get restarted 'on error'.

As I got from debugging https://github.com/testcontainers/testcontainers-java/blob/816b8c309ba526b4f34a9970f9f5e9918ad47d06/core/src/main/java/org/testcontainers/containers/output/WaitingConsumer.java#L85 becomes null when the container is going to start successfully, it's really strange. It contains lines from a stacktrace when the container is going to be restarted and null when it's running :suspect:

Any ideas? Thanks.

p.s. of course I see the desired log of the C in my terminal using docker logs C

[stale[bot]]

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.

[Mingela]

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.

Would be good to grab some attention from devs

[olarende-tink]

Can confirm that this issue is affecting me as well. LogConsumers also have problems with restarting containers: the first container's logs are captured, but not subsequent containers.

[abendt]

we also ran into that issue and created a setup to reproduce the issue: https://github.com/abendt/TestContainersWaitStrategy

in our scenario we are restarting the docker compose container programatically

to reproduce: run the main method here: https://github.com/abendt/TestContainersWaitStrategy/blob/main/src/main/kotlin/demo/Main.kt#L15

you can see that restart of the docker compose container will fail then (https://github.com/abendt/TestContainersWaitStrategy/blob/main/src/main/kotlin/demo/Main.kt#L34)