Docker Compose V2: wait strategy cannot be applied: service not found

[artamonovkirill]

Describe the bug

While running with Docker Compose V2, compose tests with wait strategies like TestDockerComposeWithWaitForService from this repository:

=== RUN   TestDockerComposeWithWaitForService
Network a7b7aa95-7973-4113-b7d9-0b98c56e7557_default  Creating
Network a7b7aa95-7973-4113-b7d9-0b98c56e7557_default  Created
Container a7b7aa95-7973-4113-b7d9-0b98c56e7557-nginx-1  Creating
Container a7b7aa95-7973-4113-b7d9-0b98c56e7557-nginx-1  Created
Container a7b7aa95-7973-4113-b7d9-0b98c56e7557-nginx-1  Starting
Container a7b7aa95-7973-4113-b7d9-0b98c56e7557-nginx-1  Started
    compose_test.go:390: Failed when running []: one or more wait strategies could not be applied to the running containers: service with name nginx_1 not found in list of running containers

To Reproduce

Either:

• Run tests from this repo on Mac or Windows with Docker Compose V2 enabled
• Run tests from this repo on Linux after installing Docker Compose V2
• Run tests on this branch
  • Changed docker-compose to docker compose, see the diff
  • Test results

Expected behavior

Container startup is awaited.

docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.3)
  compose: Docker Compose (Docker Inc., v2.0.0)
  scan: Docker Scan (Docker Inc., v0.8.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 10
 Server Version: 20.10.8
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e25210fe30a0a703442421b0f60afac609f950a3
 runc version: v1.0.1-0-g4144b63
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.47-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 1.942GiB
 Name: docker-desktop
 ID: 3JCN:ETYF:VD6H:3K6P:4STO:K6EI:CBF5:EIG3:SNN5:MFKI:OPIX:GSXA
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional Information:
This is caused by a breaking change in Docker Compose V2.

I tried installing Docker Compose V2 on ubuntu-latest nodes in GitHub Actions following this instruction, but docker-compose was still V1.

Workaround
Prefix your compose up command with the --compatibility flag.

[mdelapenya]

Hey @artamonovkirill, thanks for opening this issue. Would you mind adding a scenario (code/snippet/project) where we could reproduce this issue? Thanks in advance!

[artamonovkirill]

Hi, @mdelapenya , as mentioned - it's for the TestDockerComposeWithWaitForService from this repo. I've added the link to my first comment, too.

I'll try to fork the repo and enable running the tests on MacOS later today (if GitHub actions support Docker for Mac).

[mdelapenya]

I'll give a try once I have certain bandwidth, thanks for the report!

[artamonovkirill]

Created #377

Running tests on a Mac will be a bit trickier:

• Docker is not installed on Mac nodes
• Depending on the architecture, tests like TestDockerComposeWithWaitLogStrategy would fails (if it's ARM)

[artamonovkirill]

Caused by docker/for-mac#6035, it's actually a valid Docker Compose V2 behavior, see e.g. docker/compose#229

[artamonovkirill]

@mdelapenya updated the issue description (since it's not just Mac or Windows-specific, but rather Docker Compose V2 related).

[Malinskiy]

Unfortunately, this is not the full fix for the issue: short-running containers e.g. initialisation of some sort and wait strategy like wait.ForExit() in general might not have a container running during the wait strategy execution so the search for the container will fail unless an option for All is specified in the docker query for list

To reproduce:

1. Use a service container that just does echo Hello and exits
2. Add a wait strategy for exitcode 0
3. Run the compose up

The fix involves adding All: true to the

testcontainers-go/compose.go

Line 183 in 097f9af

containerListOptions := types.ContainerListOptions{Filters: f}

Could someone please reopen the issue?