testcontainers / testcontainers/testcontainers-python

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

Đang mở
#715 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Ngôn ngữ chính
Python
Star
2.3k
Fork
386
Merge trung bình
4 giờ 40 phút
Pull request đã merge (30 ngày)
1

Mô tả

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

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu bằng cách đọc entry point wait_for_logs và phần truy cập trạng thái wrapped-container của DockerContainer được hiển thị trong reproduction. Xác minh cách trạng thái container được quan sát trong vòng lặp chờ và cách raise_on_exit xử lý các trạng thái đã tạo và đang chạy. Được xem là hoàn tất khi ví dụ PostgreSQL không còn phát sinh exception trong lúc container đang chạy và một lần thoát thực sự được phát hiện sau khi làm mới trạng thái.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
docker, postgresql, python
Lĩnh vực
testing-qa
Loại issue
Lỗi
Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Khá rõ ràng
Mức phù hợp với người mới
45/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.