testcontainers / testcontainers/testcontainers-python

Bug: `raise_on_exit` feature of `wait_for_logs` does not work as expected

Open
#715 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
2.3k
Forks
386
Avg merge
4h 40m
Merged PRs (30d)
1

Description

Describe the bug

The raise_on_exit feature of wait_for_logs does not work as expected because it

  • considers the container "exited" when it is still in the "created" state immediately after being started
  • because it does not refresh the container state in the wait loop, so it will never see a change of state

To Reproduce

from testcontainers.core.container import DockerContainer
from testcontainers.core.waiting_utils import wait_for_logs

container = DockerContainer(image="postgres:16").with_env("POSTGRES_PASSWORD", "password")
container.start() ;
wait_for_logs(container, "something", raise_on_exit=True)
print(container.get_wrapped_container().status)
container.get_wrapped_container().reload()
print(container.get_wrapped_container().status)

The above code will raise "RuntimeError: Container exited before emitting logs satisfying predicate". This is not true, though, because the container does not exit. Checking container.get_wrapped_container().status as wait_for_logs does shows "created". This triggers the raise in wait_for_logs because that only accepts "running".

The second problem is visible here, too, because container.get_wrapped_container().status stays "created" even when the container is running. The wait_for_logs function would have to call reload on the wrapped container to actually see it change state and see when it does exit.

Runtime environment

Provide a summary of your runtime environment. Which operating system, python version, and docker version are you using? What is the version of testcontainers-python you are using? You can run the following commands to get the relevant information.

# Get the operating system information (on a unix os).
$ uname -a
Linux notebook-marc 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 30 12:02:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

$ python --version
Python 3.11.2

$ docker info
Client: Docker Engine - Community
 Version:    27.3.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.17.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.29.7
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 34
 Server Version: 27.3.1
 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: 7f7fdf5fed64eb6a7caf99b3e12efcf9d60e311c
 runc version: v1.1.14-0-g2c9f560
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.8.0-45-generic
 Operating System: Ubuntu 24.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 31.05GiB
 Name: notebook-marc
 ID: e686d3ff-941b-46b8-a412-ec0772e8f5c0
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

$ pip freeze
certifi==2024.8.30
charset-normalizer==3.4.0
docker==7.1.0
idna==3.10
requests==2.32.3
testcontainers==4.8.2
typing_extensions==4.12.2
urllib3==2.2.3
wrapt==1.16.0

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the wait_for_logs entry point and the DockerContainer wrapped-container status access shown in the reproduction. Verify how the container state is observed during the wait loop and how raise_on_exit handles the created and running states. Done means the PostgreSQL example no longer raises while the container is running, and an actual exit is detected after state refresh.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, postgresql, python
Domain
testing-qa
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.