0.41.0: org.testcontainers.containers.ContainerLaunchException: Container startup failed for image alpine/socat:1.7.4.3-r0

[longliveenduro]

I get "org.testcontainers.containers.ContainerLaunchException: Container startup failed for image alpine/socat:1.7.4.3-r0" when I use 0.41.0.

Works perfect when I switch back to 0.40.17.

Logs are not really saying much:

" 11:35:11.408 [zio-default-blocking-1] INFO tc.alpine/socat:1.7.4.3-r0 - Creating container for image: alpine/socat:1.7.4.3-r0 11:35:11.420 [zio-default-blocking-1] ERROR tc.alpine/socat:1.7.4.3-r0 - Could not start container "

[Prillan]

I'm also seeing this for 0.41.0.

[dzanot]

Do your compose service names contain the - character? I saw this, and mine did, but fixed when I removed them.

example:

services:
  app-2:
    ...

becomes:

services:
  app2:
    ...

with a corresponding update in the test:

 ExposedService("app-2", 9130, Wait.forListeningPort())

becomes

 ExposedService("app2", 9130, Wait.forListeningPort())

[longliveenduro]

Thanks for the hint @dzanot. I tried your suggestion, but still got the same error. Switched back to 0.40.17 with your proposed changes, and there it works. So i made no mistake by removing the minus character from service names.

My test now looks like:

  val serviceName = "zgeolocationservice_1"
  val port        = 9000

  object TestLayers:
    val dockerComposeTestcontainer: ZLayer[Any, Throwable, DockerComposeContainer] =
      ZLayer.scoped(
        ZIO.acquireRelease:
          ZIO
            .attempt(
              DockerComposeContainer.Def(
                ComposeFile(Left(composeFileInIntellijOrSbtConsole)),
                Seq(ExposedService(serviceName, port)),
                env = Map("COMPOSE_PROFILES" -> "all"),
                [....]

[dzanot]

Dang sorry it didn't work. I landed there by watching the docker container start in docker desktop, it was named app-2-1 and when I explicitly put that as service name in the test it worked. Then after i just tried dropping the - altogether.

[dzanot]

@longliveenduro we just ran into this again when a dockerCompose.container.withOptions("--compatibility") snuck into our config. This flag is no longer supported with the docker-compose -> docker compose transition of testcontainers 0.41.0

[longliveenduro]

@dzanot Thanks, but I don't use "--compatibility" in my test.

[longliveenduro]

@dzanot My fault, just took some time to dive into compose v2, and migrated my test. Works now!

[skisel-bt]

It took me a while to learn that the interface has changed for getServiceHost and getServicePort to accept not the servicename_1 as before, but servicename, so not about - character but also _