testcontainers / testcontainers/testcontainers-python

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

Ouverte
#715 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

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

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. 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

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.