[Bug]: Running testcontainers temporarily changes global uncaught exception handler

Comienza con DockerClientProviderStrategy.test y el shaded Awaitility ConditionAwaiter mostrado en el stack trace; después, revisa cómo el inicio del contenedor inicializa la detección de Docker. Verifica que ejecutar Testcontainers no deje instalado un controlador global de excepciones no capturadas diferente y que las excepciones de otros hilos sigan llegando al controlador previsto.

Module

Core

Testcontainers version

2.0.3

Using the latest Testcontainers version?

Yes

Host OS

MacOS

Host Arch

ARM

Docker version

Client:
 Version:           28.5.2
 API version:       1.51
 Go version:        go1.25.3
 Git commit:        ecc6942
 Built:             Wed Nov  5 14:42:30 2025
 OS/Arch:           darwin/arm64
 Context:           orbstack

Server: Docker Engine - Community
 Engine:
  Version:          28.5.2
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.9
  Git commit:       89c5e8f
  Built:            Wed Nov  5 14:43:35 2025
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.2.0
  GitCommit:        1c4457e00facac03ce1d75f7b6777a7a851e5c41
 runc:
  Version:          1.3.3
  GitCommit:        d842d7719497cc3b774fd71620278ac9e17710e0
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?

When executing tests with containers managed by testcontainers, the global uncaught exception handler is being changed and uncaught exceptions are being intercepted by testcontainers instead of the intended exception handler.

The example stacktrace where this is happening

at java.lang.Thread.setDefaultUncaughtExceptionHandler(Thread.java:2496)
at org.testcontainers.shaded.org.awaitility.core.ConditionAwaiter.<init>(ConditionAwaiter.java:59)
at org.testcontainers.shaded.org.awaitility.core.AssertionCondition$1.<init>(AssertionCondition.java:64)
at org.testcontainers.shaded.org.awaitility.core.AssertionCondition.<init>(AssertionCondition.java:64)
at org.testcontainers.shaded.org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:790)
at org.testcontainers.dockerclient.DockerClientProviderStrategy.test(DockerClientProviderStrategy.java:214)
at org.testcontainers.dockerclient.DockerClientProviderStrategy.tryOutStrategy(DockerClientProviderStrategy.java:284)
at org.testcontainers.dockerclient.DockerClientProviderStrategy.lambda$getFirstValidStrategy$5(DockerClientProviderStrategy.java:263)
at org.testcontainers.dockerclient.DockerClientProviderStrategy$$Lambda/0x00000ff001259730.test(Unknown Source:-1)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:196)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197)
at java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1693)
at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:147)
at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:588)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:574)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:150)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265)
at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:683)
at org.testcontainers.dockerclient.DockerClientProviderStrategy.getFirstValidStrategy(DockerClientProviderStrategy.java:264)
at org.testcontainers.DockerClientFactory.getOrInitializeStrategy(DockerClientFactory.java:154)
at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:196)
at org.testcontainers.DockerClientFactory$1.getDockerClient(DockerClientFactory.java:108)
at com.github.dockerjava.api.DockerClientDelegate.authConfig(DockerClientDelegate.java:109)
at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:316)
...

Furthermore, intercepting uncaught exceptions from other threads could, at least in theory, lead to testcontainers appearing to be flaky, but I haven't reproduced that.

Relevant log output

Additional Information

This is done by awaitility, which testcontainers uses and shades and its intentional (and configurable) behavior of that library

• https://github.com/awaitility/awaitility/issues/120

This caused flakiness in our tests, but there we were using awaitility directly, not via testcontainers code.

• https://github.com/trinodb/trino/pull/28055