Parent: #1936
Problem
The core gittensory service's depends_on in docker-compose.yml only gates on redis and qdrant (condition: service_healthy) — it never depends on postgres or pgbouncer, even though --profile postgres/--profile pgbouncer are documented first-class deployment modes.
On docker compose --profile postgres up -d (or --profile pgbouncer) with a cold Postgres volume, Docker starts gittensory immediately in parallel with postgres initdb instead of waiting for the healthcheck. The app's own waitForPostgres() fallback (src/server.ts, ~30s hard cap) then races the Postgres image pull + first-run initialization; on a slow disk/first pull this commonly exceeds 30s, causing gittensory to throw and crash-loop via restart: unless-stopped before Postgres becomes reachable, rather than compose holding it back cleanly.
Fix
Add postgres: condition: service_healthy, required: false (and pgbouncer: condition: service_healthy, required: false) to the gittensory service's depends_on block, mirroring the existing qdrant pattern, so compose-level ordering covers the Postgres/PgBouncer path the same way it already covers Qdrant.
Verification
Parent: #1936
Problem
The core
gittensoryservice'sdepends_onindocker-compose.ymlonly gates onredisandqdrant(condition: service_healthy) — it never depends onpostgresorpgbouncer, even though--profile postgres/--profile pgbouncerare documented first-class deployment modes.On
docker compose --profile postgres up -d(or--profile pgbouncer) with a cold Postgres volume, Docker startsgittensoryimmediately in parallel withpostgresinitdb instead of waiting for the healthcheck. The app's ownwaitForPostgres()fallback (src/server.ts, ~30s hard cap) then races the Postgres image pull + first-run initialization; on a slow disk/first pull this commonly exceeds 30s, causinggittensoryto throw and crash-loop viarestart: unless-stoppedbefore Postgres becomes reachable, rather than compose holding it back cleanly.Fix
Add
postgres: condition: service_healthy, required: false(andpgbouncer: condition: service_healthy, required: false) to thegittensoryservice'sdepends_onblock, mirroring the existingqdrantpattern, so compose-level ordering covers the Postgres/PgBouncer path the same way it already covers Qdrant.Verification
depends_onblock againstdocker-compose.yml(line numbers may have shifted).docker compose --profile postgres up -danddocker compose --profile pgbouncer up -dfrom a cold volume no longer crash-loop the core app on first boot.required: falsecorrectly keeps the default (no-profile) SQLite path unaffected.