Bug: wait_for_logs on DockerCompose container fails

[gzt5142]

Describe the bug

Attempting to wait_for_logs on a docker compose container is failing. Cause seems to be .decode() being used twice (i.e. attempt to .decode() a string already decoded earlier).

• wait_for_logs is .decode()-ing here the result of DockerCompose.get_logs()
• DockerCompose.get_logs() here has already decoded the stdout byte stream.
• Attempt to decode a string object fails.

To Reproduce

from testcontainers.compose import DockerCompose
from testcontainers.core.waiting_utils import wait_for_logs
compose = DockerCompose("./docker/", compose_file_name="docker-compose.yml", services=['slim-db'])
compose.start()
delay = wait_for_logs(compose, "database system is ready to accept connections")

produces an AttributeError:

AttributeError                            Traceback (most recent call last)
----> [1] delay = wait_for_logs(compose, "database system is ready to accept connections")

File ~/myproject/.venv/lib/python3.12/site-packages/testcontainers/core/waiting_utils.py:102, in wait_for_logs(container, predicate, timeout, interval)
    100 while True:
    101     duration = time.time() - start
--> 102     stdout = container.get_logs()[0].decode()
    103     stderr = container.get_logs()[1].decode()
    104     if predicate(stdout) or predicate(stderr):

AttributeError: 'str' object has no attribute 'decode'

Runtime environment

This error arises in python versions 3.10, 3.11, and 3.12. The current environment:

% uname -a
Linux ubuntu-mate 6.5.0-44-generic #44~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Jun 18 14:36:16 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

% python --version
Python 3.12.3

% docker info
Client: Docker Engine - Community
 Version:    26.1.3
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.27.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 4
 Server Version: 26.1.3
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e377cd56a71523140ca6ae87e30244719194a521
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.5.0-44-generic
 Operating System: Ubuntu 22.04.4 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.747GiB
 Name: ubuntu-mate
 ID: 44dbea1b-0b0f-44d6-8f3f-f9d82397b2c9
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Other Notes
As a simple test, a quick patch (I removed the .decode() in the get_logs method of DockerCompose) resolves this issue for me. I have not tested (and don't really have the capacity to do so, unfortunately) the impact of this change across other parts of the code base. There may be other places which expect a string instead of a byte stream -- I don't yet know.

[alexanderankin]

how about a try catch in the wait_for_logs function/isinstance check? seems like it should solve it and just make the function tolerate either input.

flagging this for v5 in a min