You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: [minio] _healthcheck calls for nested wait_container_is_ready resulting in long wait time #578
MinioContainer._healthcheck is decorated with wait_container_is_ready and calls get_exposed_port which is also decorated wait_container_is_ready. This results in a default wait time of 120*120=14400 seconds...
As a workaround I set the testcontainers_config.max_tries manually:
if this workaround works, it means the container is coming up successfully but the healthcheck is reporting a false negative result. this means the healthcheck for minio is broken. can you confirm which os/arch/python/docker/tc you're using?
this script takes about 2 seconds to run on my mac (m1/3.12/tc runtime/4.5.0):
(.venv) $ time python script.pyusing host tcp://127.0.0.1:57980WARNING:root:DOCKER_AUTH_CONFIG is experimental, see testcontainers/testcontainers-python#566using host tcp://127.0.0.1:57980INFO:testcontainers.core.docker_client:using host tcp://127.0.0.1:57980Pulling image testcontainers/ryuk:0.7.0INFO:testcontainers.core.container:Pulling image testcontainers/ryuk:0.7.0Container started: 22927a92f547INFO:testcontainers.core.container:Container started: 22927a92f547Waiting for container <Container: 22927a92f547> with image testcontainers/ryuk:0.7.0 to be ready ...INFO:testcontainers.core.waiting_utils:Waiting for container <Container: 22927a92f547> with image testcontainers/ryuk:0.7.0 to be ready ...Pulling image minio/minio:RELEASE.2022-12-02T19-19-22ZINFO:testcontainers.core.container:Pulling image minio/minio:RELEASE.2022-12-02T19-19-22ZContainer started: 580c1203767bINFO:testcontainers.core.container:Container started: 580c1203767bWaiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...INFO:testcontainers.core.waiting_utils:Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...INFO:testcontainers.core.waiting_utils:Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...INFO:testcontainers.core.waiting_utils:Waiting for container <Container: 580c1203767b> with image minio/minio:RELEASE.2022-12-02T19-19-22Z to be ready ...[Bucket('abc')]real 0m1.855suser 0m0.258ssys 0m0.054s
Activity
alexanderankin commentedon May 26, 2024
if this workaround works, it means the container is coming up successfully but the healthcheck is reporting a false negative result. this means the healthcheck for minio is broken. can you confirm which os/arch/python/docker/tc you're using?
this script takes about 2 seconds to run on my mac (m1/3.12/tc runtime/4.5.0):
run output
sushi30 commentedon May 29, 2024
I can confirm this issue is with elasticsearch too.. Just but a debugger in

waiting_utilsand you'll the nested calls:alexanderankin commentedon May 29, 2024
the nested calls are fine - you do need to wait for all of that before getting mapped ports
sushi30 commentedon May 29, 2024
but shouldn't the total timeout be 120 seconds? the nested calls should have awareness of how much time passed since the container was started.
alexanderankin commentedon May 29, 2024
that could be improved, i agree, but in general it doesn't introduce new errors