[Bug]: Starting with 1.20.2 we can no longer get the logs of a container that failed to start

[sorin-florea]

Module

Core

Testcontainers version

1.20.2+

Using the latest Testcontainers version?

Yes

Host OS

Macos

Host Arch

ARM

Docker version

Client:
 Version:           27.5.1
 API version:       1.47
 Go version:        go1.22.11
 Git commit:        9f9e405
 Built:             Wed Jan 22 13:37:19 2025
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.38.0 (181591)
 Engine:
  Version:          27.5.1
  API version:      1.47 (minimum version 1.24)
  Go version:       go1.22.11
  Git commit:       4c9b3b0
  Built:            Wed Jan 22 13:41:25 2025
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.7.25
  GitCommit:        bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e946
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?

Starting with 1.20.2 we can no longer get the log output of a container that failed to start. The stop method is called automatically, and that clears the containerId.

Relevant log output

Additional Information

No response

[SylvainJuge]

Hi !

I have just found an instance of this issue in elastic/apm-agent-java#4056, despite the PR name the issue was present in a previous dependabot so this indicates the problem has effectively been introduced in 1.20.2.

Trying to override stop() and getContainerId and store the container ID does not help here, and I have found that it is only the waiting strategy relying on logs that fail. Once the container has failed to start we can still read the logs and assert their content, so using a dummy command as a wait strategy was enough for us to work-around this.

EDIT: this strategy also makes the test unreliable if you need to parse the log output, what I found to be more effective is to still wait on the log content regex, but make sure to assert on something that is after what you are looking for (in my case it was a specific error message at the start of the container output).