Skip to content

Decouple in-container DB_PORT from host-side env (BS#959)#963

Merged
jakebromberg merged 1 commit into
mainfrom
fix-959-db-port-conflation
May 19, 2026
Merged

Decouple in-container DB_PORT from host-side env (BS#959)#963
jakebromberg merged 1 commit into
mainfrom
fix-959-db-port-conflation

Conversation

@jakebromberg
Copy link
Copy Markdown
Member

Closes #959.

Summary

  • Hardcode DB_PORT=5432 in the ci-profile backend service env in dev_env/docker-compose.yml — matches the convention already in place on every other consumer service.
  • Add tests/unit/scripts/docker-compose-db-port.test.ts (parameterized over 8 services) to pin the invariant going forward.

Why

The backend service was the only consumer with DB_PORT=${DB_PORT:-5432}. Every other consumer (db-init, ci-db-init, auth, e2e-db-init, e2e-auth, e2e-backend, etl-db-init) hardcodes 5432. The DB_PORT env var has two distinct uses in docker-compose.yml:

Use Lines Intent
Host port mapping db.ports: '${DB_PORT:-5432}:5432' Bind the postgres container's 5432 to whatever host port the user wants
In-container connection target backend.environment: DB_PORT=… Tell the app process what port to dial inside the docker network — always 5432 because that's what the postgres image listens on

Conflating them — writing DB_PORT=${DB_PORT:-5432} in the consumer's env — lets a stray .env value leak through. The dev profile defaults DB_PORT=5436 for the host mapping; copying that .env into a ci-profile setup makes the backend container try to dial ci-db:5436, which fails because ci-db still listens on 5432 inside the docker network. The visible symptom was Invalid argument / 503 from the backend healthcheck on npm run ci:testmock.

Same shape as the closed #413 fix for AUTH_PORT.

Scope

One line changed in dev_env/docker-compose.yml. The other host-port-mapping vars (DB_PORT, CI_DB_PORT, E2E_DB_PORT, ETL_PG_PORT) are unchanged — those legitimately need env substitution so different worktrees can run on different host ports.

The new test covers all 8 consumer services, not just backend, so a future regression elsewhere fails CI before reaching merge.

Test plan

  • npx jest --testPathPatterns docker-compose-db-port — 8/8 pass.
  • Full unit suite (npm run test:unit) — 1984/1984 pass.
  • Typecheck + format:check clean.
  • CI Integration-Tests job runs to completion against a .env that does not set DB_PORT (the default; this is what GHA does today).
  • Manual: npm run ci:testmock with .env containing DB_PORT=5436 no longer breaks.

Related

  • #413 — same shape, closed, on AUTH_PORT.
  • #955 — the incident where this conflation manifested.
  • #958 — the broader env-surface divergence between local and GHA CI; this PR closes one symptom of that umbrella.

The ci-profile `backend` service was the only consumer with `DB_PORT=${DB_PORT:-5432}` — every other service (`ci-db-init`, `auth`, `e2e-*`, `etl-db-init`) already hardcodes `5432`. When a stray `.env` has `DB_PORT=5436` (the dev profile default for the host-port mapping), the env substitution leaks into the backend container's `DB_PORT` and breaks its in-network connection to `ci-db`, which still listens on `5432`.

Same shape as the closed BS#413 fix for `AUTH_PORT`. Cost on the BS#955 repro work was several rounds of chasing a "Invalid argument" / 503 healthcheck before the cause surfaced.

Pinned by a new parameterized source-grep test that covers all 8 consumer services so the same regression in a future service surfaces immediately.
@jakebromberg jakebromberg merged commit d3f27e5 into main May 19, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

dev_env/docker-compose.yml conflates DB_PORT (host port vs in-container port) Docker Compose auth containers need AUTH_PORT=8080 after default change

1 participant