[BUG] `depends_on` health/completion waits always sleep 500ms before the first check
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 35/100
Research direction
The cause is already pinpointed: the wait loop in pkg/compose/service_containers.go ticks on a 500ms time.Ticker before its first dependency check, so it sleeps even when the dependency is already healthy. Read waitDependency and restructure the loop to check first, then wait for the next tick; 'done' is a no-op docker compose up -d --wait timing near ~0.07s. Note: open pull request #14385 already targets this, so the work is underway.
Written by the indexing model from the issue text.
Description
Description
When a service waits on a dependency with condition: service_healthy or service_completed_successfully, Compose always waits 500ms before it checks the dependency for the first time, even when the dependency is already healthy. up --wait pays this delay again in its final check. As a result, a no-op docker compose up -d takes ~0.6s instead of ~0.07s, and up -d --wait takes ~1.1s instead of ~0.07s.
The cause is waitDependency in pkg/compose/service_containers.go: the loop waits on a 500ms time.Ticker before the first check. The loop has had this shape since 2021.
Steps To Reproduce
-
Create compose.yaml
services: db: image: alpine:3.20 command: sleep infinity init: true healthcheck: test: ["CMD", "true"] interval: 1s start_interval: 1s start_period: 5s app: image: alpine:3.20 command: sleep infinity init: true depends_on: db: condition: service_healthy -
Run
docker compose up -d --waitonce, so that everything is up and healthy. -
Time a no-op run:
time docker compose up -dandtime docker compose up -d --wait.
Compose Version
Docker Compose version v5.6.1
Docker Environment
Anything else?
No response
- Dominant language
- Go
- Stars
- 38.5k
- Forks
- 5.9k
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 63
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from docker/compose
-
[BUG] deploy.restart_policy without condition drops the restart policyPossibly taken @akshat-lakhera claimed this 2 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
docker/compose#14383 · 1 comment ·
Maintainers usually reply within 1 day
-
kind/bug status/0-triage
Difficulty 3/5 1-2 days Newbie friendliness 56/100
docker/compose#14386 · 1 comment ·
Maintainers usually reply within 1 day
-
[BUG] down -v removes a named volume owned by another projectPossibly taken @htoyoda18 claimed this 5 days ago. Openkind/bug
Difficulty 3/5 1-2 days Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
[BUG] A start failure in one service aborts the start of unrelated services (unreleased regression)Openkind/bug
Difficulty 4/5 3-5 days Newbie friendliness 57/100
docker/compose#14372 · 1 comment ·
Maintainers usually reply within 1 day
-
kind/feature
Difficulty 4/5 3-5 days Newbie friendliness 48/100
docker/compose#14365 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
area/docs theme/deployer
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
area/orchestration area/website kind/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
vllm-project/aibrix#3317 · 1 comment ·
Maintainers usually reply within 1 day
-
documentation ready
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Needs Triage
Difficulty 1/5 Under an hour Newbie friendliness 90/100