testcontainers / testcontainers/testcontainers-python
Bug: `raise_on_exit` feature of `wait_for_logs` does not work as expected
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 2.3k
- Forks
- 386
- Merge moyen
- 4 h 40 min
- PR mergées (30 j)
- 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
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par lire le point d’entrée wait_for_logs et l’accès à l’état de wrapped-container de DockerContainer montré dans la reproduction. Vérifiez comment l’état du conteneur est observé pendant la boucle d’attente et comment raise_on_exit gère les états créé et en cours d’exécution. C’est terminé lorsque l’exemple PostgreSQL ne lève plus d’exception tant que le conteneur est en cours d’exécution et qu’une sortie réelle est détectée après l’actualisation de l’état.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- docker, postgresql, python
- Domaine
- testing-qa
- Type d'issue
- Bug
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100