DockerComposeContainer doesn't report underlying issue on start failure.

[wong-git]

This isn't necessarily a bug but it seems like its a gap in the start up error reporting.

When starting up a test containers, it's failing with the following "Caused by" stacktrace:

Caused by: org.rnorth.ducttape.RetryCountExceededException: Retry limit hit with exception at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:88) at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:329) ... 150 more Caused by: org.testcontainers.containers.ContainerLaunchException: Could not create/start container at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:525) at org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:331) at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:81) ... 151 more Caused by: java.lang.IllegalStateException: Container did not start correctly. at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:463) ... 153 more

None of this is particularly informative.

When directly starting up docker with the same docker-compose.yml, this was reported:

docker-compose -f docker-compose.yml up -d
[+] Running 0/0
 ⠿ Network appevents-provisioner_default  Error                                0.0s
failed to create network appevents-provisioner_default: Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network

Another member on our team directed me to docker network ls:

docker network ls
NETWORK ID     NAME                   DRIVER    SCOPE
1092d4876829   1eylvttsssuk_default   bridge    local
aa08e32c77c6   4fq4vqxbmq2e_default   bridge    local
b9cc9d2c02ea   4gtpimii42dc_default   bridge    local
6f9835452949   bbfhuyndyhge_default   bridge    local
1ae2f01181dd   bridge                 bridge    local
87d9755d65db   ckg9bdaghx2m_default   bridge    local
54bf8b4e66b4   drdafrr8vcuw_default   bridge    local
633a08e00dc8   egj2dr2nhju9_default   bridge    local
42706dd28d31   ghy6amkgx1qr_default   bridge    local
60e415e7890a   gjlmzqcqbyx1_default   bridge    local
8b788e8024a7   h7limppelzbm_default   bridge    local
f8143f373104   hg92szytffyx_default   bridge    local
a2cdb1b4f724   host                   host      local
ada646935572   ictsr19kolym_default   bridge    local
dd94b53a031a   isfskvbc5ixn_default   bridge    local
6cbc5196ca00   izx7kabwwwja_default   bridge    local
4c0fcf45402d   jmushtb7tbix_default   bridge    local
08749d2a7159   k4dugcecebye_default   bridge    local
180ac01fdc35   ks1bev5sildx_default   bridge    local
6ea09990ab86   local_default          bridge    local
9bfb392c156a   mnsecpxyfd9n_default   bridge    local
33f5e7d4a820   ndfqhau1lo1r_default   bridge    local
22ea5a41c9e7   none                   null      local
7c5106cbd5cb   owsqlsjrqmyp_default   bridge    local
d9abe014132f   puij6flbbupl_default   bridge    local
64251795e5ad   r8fq5rm7ny7i_default   bridge    local
b6cc47999a56   rd6mz2aw21vw_default   bridge    local
863c97bd163c   v8cetmwucp3c_default   bridge    local
da195e1d5c01   wdzbew1jmgb6_default   bridge    local
350928c753a5   wzeekb96naqr_default   bridge    local
7934aacf3e73   yjqlo6ve261q_default   bridge    local
dde63911c6ce   zg8uxue47oeh_default   bridge    local

So I googled and discovered "docker network prune -f"

It would have been helpful if the testcontainers start failure had explicitly said what the underlying problem was rather than just "Container did not start correctly."

Thanks,

-Jonathan

[mcgizzle]

Plus one on this

[FlyingZC]

I have the same problem, is there any way to solve it?

[kiview]

Thank you @wong-git, you are right that this would a usability improvement.

In general, since using Docker Compose means Docker Compose will take some responsibilities, those kind of issues might happen and in general we recommend using Testcontainers directly instead of through Docker Compose, to give Testcontainers more control over the environment.

@FlyingZC What is your problem? This issue is not about any problem with DockerComposeContainer, but about the lack of communicating underlying issues during startup (which are likely Docker or Compose related).

[FlyingZC]

I can only circumvent this problem by starting the docker process a few times less per test process.

[rombert]

For me, it would be useful to be able to diagnose exactly why compose was unable to start, e.g.

• inspect container states to see which ones have failed
• dump logs for failing containers

We have a docker-compose setup for development which we reuse for running integration tests. Using testcontainers exclusively would mean that we'd have to duplicate the docker-compose setup in Java code, which is non-trivial.

[LikeSimple]

Can't use Docker Compose V2