Containers not shut down between tests when using .withReuse(true) but env. does not support reuse (e.g. CI builds)

[jgracin]

Hi!

When an environment does NOT support container reuse (i.e. .testcontainers.properties does not have testcontainers.reuse.enabled=true), but a container is set up using container.withReuse(true), Testcontainers Java decides that the container is not reusable. However, the isShouldBeReused() method continues to return true, because it only reflects the values set by .withReuse().

Spring Boot Testcontainers module in TestcontainersLifecycleBeanPostProcessor.postProcessBeforeDestruction() checks container.isShouldBeReused() and decides it will not shut down the container even though the container cannot be reused because the environment does not support it.

This results in multiple instances of the same containers running, potentially exhausting the build machine resources. (In GH Actions, this often manifests as "build stuck in tests", because the machine is not able to spawn any more container instances.)

A workaround that I'm currently using is that, instead of unconditionally using .withReuse(true) in test setup, I use

if (TestcontainerConfiguration.getInstance().environmentSupportsReuse() {
  container.withReuse(true);
}

It seems that fixing this will probably need Testcontainers Java changes, I plan to raise an issue there as well.

Using Spring Boot 3.2.0, and Java 21.

[scottfrederick]

@jgracin Please add a comment with the link to a Testcontainers issue when you create one. We can decide what, if anything to do in Spring Boot once we see what the Testcontainers team wants to do.

[jgracin]

The issue in Testcontainers is testcontainers/testcontainers-java#8323

[philwebb]

The test containers issue doesn't seem to be getting any traction as yet. I think we could change TestcontainersLifecycleBeanPostProcessor.isReusedContainer to do the same TestcontainerConfiguration.getInstance().environmentSupportsReuse() check. We can always change again if a better approach is available later.