Concurrent CI runs kill each other's Postgres (fixed container name + port in ci.yml) #165

New issue

Closed

opened 2026-08-01 02:18:10 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-08-01 02:18:10 +00:00

Contributor

Discovered while landing #163/#164: both PRs' CI runs started two minutes apart (runs 141 and 142, 2026-08-01 01:31/01:33) and both failed, while the identical branches passed the full suite + ruff on the dev server. A solo rerun of each branch went green.

Root cause

ci.yml's docker-in-job Postgres uses a fixed container name and fixed host port:

docker rm -f ci-postgres runs at the start of every job (ci.yml:48) — when two runs overlap on the shared runner host, the second run force-removes the first run's live database mid-suite.
Both publish -p 5432:5432, so even without the rm, the second docker run would fail on the port bind.

Any two PRs whose CI overlaps produce spurious double-red — and worse, the failure mode looks like test flakiness, not infrastructure.

Fix

Name the container per run: ci-postgres-${GITHUB_RUN_ID} (scope the pre-clean rm -f and the always() teardown to that name).
Publish an ephemeral host port (-p 5432) and have the wait-and-detect step discover the mapped port via docker port, exporting PG_PORT alongside PG_HOST for the migration/test steps.

Source: CI failure investigation for #163/#164, Claude session 2026-08-01.

Discovered while landing #163/#164: both PRs' CI runs started two minutes apart (runs 141 and 142, 2026-08-01 01:31/01:33) and **both failed**, while the identical branches passed the full suite + ruff on the dev server. A solo rerun of each branch went green. ## Root cause `ci.yml`'s docker-in-job Postgres uses a **fixed container name and fixed host port**: - `docker rm -f ci-postgres` runs at the start of every job (ci.yml:48) — when two runs overlap on the shared runner host, the second run **force-removes the first run's live database mid-suite**. - Both publish `-p 5432:5432`, so even without the rm, the second `docker run` would fail on the port bind. Any two PRs whose CI overlaps produce spurious double-red — and worse, the failure mode looks like test flakiness, not infrastructure. ## Fix - Name the container per run: `ci-postgres-${GITHUB_RUN_ID}` (scope the pre-clean `rm -f` and the `always()` teardown to that name). - Publish an ephemeral host port (`-p 5432`) and have the wait-and-detect step discover the mapped port via `docker port`, exporting `PG_PORT` alongside `PG_HOST` for the migration/test steps. Source: CI failure investigation for #163/#164, Claude session 2026-08-01.