Severity
Medium — CI reliability and diagnosability during release hardening.
Problem
Six PostgreSQL startup steps still use this pattern:
for i in $(seq 1 30); do
docker exec ... pg_isready ... && break
sleep 1
done || { echo "PG not ready"; exit 1; }
The done || ... handler is ineffective: if PostgreSQL never becomes ready, the final sleep 1 succeeds, so the loop itself exits successfully. The setup step goes green and a later install/test step fails with a less actionable connection error and without container logs.
Affected jobs in .github/workflows/ci.yml:
- PostgreSQL matrix
- frozen stable smoke
- Python client
- Go client
- TypeScript client
- Ruby client
The upgrade, pg_tle, pg_cron, and pg_timetable jobs already use an explicit ready flag and fail closed, so behavior is inconsistent within the same workflow.
Expected fix
- Convert every remaining loop to an explicit success flag (or a tested shared helper).
- Probe the actual target database with
psql -c 'select 1' where initialization completion matters, rather than accepting the temporary init server.
- On timeout, print
docker logs <container> and exit nonzero in the startup step.
- Add a lightweight shell regression/static assertion so future jobs cannot reintroduce the broken
done || form.
This is the incomplete remainder of the readiness work discussed around #286.
Severity
Medium — CI reliability and diagnosability during release hardening.
Problem
Six PostgreSQL startup steps still use this pattern:
The
done || ...handler is ineffective: if PostgreSQL never becomes ready, the finalsleep 1succeeds, so the loop itself exits successfully. The setup step goes green and a later install/test step fails with a less actionable connection error and without container logs.Affected jobs in
.github/workflows/ci.yml:The upgrade, pg_tle, pg_cron, and pg_timetable jobs already use an explicit
readyflag and fail closed, so behavior is inconsistent within the same workflow.Expected fix
psql -c 'select 1'where initialization completion matters, rather than accepting the temporary init server.docker logs <container>and exit nonzero in the startup step.done ||form.This is the incomplete remainder of the readiness work discussed around #286.