Compose container logs are only captured for successful starts

[jalaziz]

Expected Behaviour

When enabling log capture for docker compose, all containers logs should be capture regardless of the success of docker compose up

Actual Behaviour

Container logs are only captures if the compose stack successfully starts. This is related to #685.

Testcontainer Logs
...

Steps to Reproduce

1. Enable container log capture: export DEBUG="testcontainers*"
2. Use a configuration with a failing dependency:

   version: '3.8'
   services:
     redis:
       image: redis:alpine
       healthcheck:
         test: ["CMD-SHELL", "exit 1"]
         interval: 5s
         timeout: 3s
         retries: 5
         start_period: 10s
     hello:
       image: nginxdemos/hello
       ports:
         - "8080:80"
       depends_on:
         redis:
           condition: service_healthy
   

3. Use testcontainers to start the compose stack:

   let environment = new DockerComposeEnvironment(
     __dirname,
     'docker-compose.yml',
   ).withDefaultWaitStrategy(Wait.forHealthCheck());
   await environment.up();
   

4. Notice that the stack will fail to start without printing any container logs.

Environment Information

• Operating System: Ubuntu 24.04.3 LTS
• Docker Version: 28.0.4
• Node version: 24.10.0
• Testcontainers version: 11.0.3

[jalaziz]

The problem seems to stem from the fact that this library doesn't not attempt to collect container logs until up is successful. However, this behavior makes it nearly impossible to capture logs of failing containers that are preventing the stack from successfully starting.

[cristianrgreco]

HI @jalaziz,

This seems to be a limitation in the downstream docker-compose library. Run the usage example with logs enabled and you'll see the output as you see in testcontainers. I would raise the issue there.

const path = require("node:path");
const compose = require('docker-compose');

compose.upAll({ cwd: path.join(__dirname), log: true }).then(
  () => {
    console.log('done')
  },
  (err) => {
    console.log('something went wrong:', err.message)
  }
)

node index.js 
time="2025-12-30T12:05:25Z" level=warning msg="/Users/cristian/Desktop/testcontainers-1210/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion"
 Network testcontainers-1210_default  Creating
 Network testcontainers-1210_default  Created
 Container testcontainers-1210-redis-1  Creating
 Container testcontainers-1210-redis-1  Created
 Container testcontainers-1210-hello-1  Creating
 Container testcontainers-1210-hello-1  Created
 Container testcontainers-1210-redis-1  Starting
 Container testcontainers-1210-redis-1  Started
 Container testcontainers-1210-redis-1  Waiting
 Container testcontainers-1210-redis-1  Error
dependency failed to start: container testcontainers-1210-redis-1 is unhealthy
something went wrong: undefined

[jalaziz]

Hi @cristianrgreco,

I did some digging and it's not a limitation in the underlying library. Ultimately, docker-compose is a very thin wrapper around the compose CLI, so it ultimately behaves the same way. By default, the underlying docker-compose library runs compose up -d which won't collect logs in the foreground. However, if you use --attach, --attach-dependencies, or one of several other options then it will run in foreground mode where the logs will be collected.

Thanks to the recently added withClientOptions, we can pass those command options to the underlying library. HOWEVER, when running in foreground mode, the promise returned by up does not resolve until the process exits. Since test-container awaits on the promise, it effectively gets stuck.

Since test-containers seems to rely on the detached behavior of not returning until all containers have started, a viable solution may be to:

1. Call up without an await
2. Call logs in follow mode to start capturing the logs
3. Then await on the promise returned from up

The main challenge I see here is not having a good way to kill the logs --follow process.

Alternatively, it may be possible to just call logs right after up fails to capture logs (but I haven't tested this yet).

[jalaziz]

I think I figured out a better option:

1. Call compose.up with --no-start
2. Get all the services and attach the logger
3. Call compose.start
4. Continue as normal

[cristianrgreco]

I think I figured out a better option:

1. Call compose.up with --no-start
2. Get all the services and attach the logger
3. Call compose.start
4. Continue as normal

Oh that's interesting. Have you tested that you're able to attach loggers in this case? I would've thought calling up with --no-start would mean there's no container to attach to

[jalaziz]

I think I figured out a better option:

1. Call compose.up with --no-start
2. Get all the services and attach the logger
3. Call compose.start
4. Continue as normal

Oh that's interesting. Have you tested that you're able to attach loggers in this case? I would've thought calling up with --no-start would mean there's no container to attach to

I tried using the CLI and docker compose logs -f <service> will work with a container that is created but not started. As soon as the container starts, logs start printing.

I'm not sure if the CLI does anything fancy here compared to the dockerode client, but docker-compose should behave similarly since it uses the CLI (with the caveat of it spawning a process).

[cristianrgreco]

As long as it's not detrimental to performance (delayed container start) I'd be down to review a PR if you have time.