Bug: MongoDB container is reported ready before the server accepts connections
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 65/100
Direzione di ricerca
Look at the MongoDbContainer class in testcontainers/mongodb.py to understand the current wait strategy. The fix involves updating the wait strategy to check for the 'Listening on' log entry with address '0.0.0.0' in JSON logs. Run the provided reproduction script to verify the bug and test the fix. Ensure the change works for MongoDB 4.4 and newer versions.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Describe the bug
When a root user is configured, which MongoDbContainer always does, the mongo image starts twice. A temporary server listening only on localhost creates the user and exits, then the real server starts. Both log "Waiting for connections", and the container's wait strategy matches the first one. So start() returns while no server is reachable from outside the container, and on a slow host the client times out before the real server is up.
I expected start() to return once the real server accepts connections. A line only the real server logs is the "Listening on" entry with address 0.0.0.0 (JSON logs, MongoDB 4.4 and newer), and waiting for r'"Listening on".*"address":"0\.0\.0\.0"' makes the snippet below pass.
To Reproduce
from testcontainers.mongodb import MongoDbContainer
# Limit the container to a tenth of a CPU, as a busy CI runner would.
with MongoDbContainer("mongo:7").with_kwargs(nano_cpus=100_000_000) as mongo:
client = mongo.get_connection_client()
print(client.admin.command("ping"))
pymongo.errors.ServerSelectionTimeoutError: localhost:50264: [Errno 54] Connection reset by peer (configured timeouts: socketTimeoutMS: 20000.0ms, connectTimeoutMS: 20000.0ms), Timeout: 30s
It fails every time at this limit and passes with nano_cpus=1_000_000_000.
Runtime environment
macOS 26 (arm64), Docker 29.7.2, Python 3.14.0, testcontainers 4.15.0. The wait strategy on main is the same.
- Lingua principale
- Python
- Stelle
- 2.3k
- Fork
- 386
- Merge medio
- 4h 40m
- PR unite (30g)
- 1
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di testcontainers/testcontainers-python
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
testcontainers/testcontainers-python#1115 · 1 reazione ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Updating the documentation Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
testcontainers/testcontainers-python#1086 · 1 commento ·
-
Bug: [minio] _healthcheck calls for nested wait_container_is_ready resulting in long wait time Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
testcontainers/testcontainers-python#578 · 5 commenti ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
Tutte le issue di testcontainers/testcontainers-python
Issue simili
-
essnmx good first issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 95/100
-
[Feature] 奇物选择添加优先级 Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
syfoud/Simulated_Scepter#174 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
Giskard-AI/giskard-oss#2840 · 1 commento ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Apertaarea: repo bug perceived difficulty: 2
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
yeti-platform/yeti#1380 ·