Replace postgres wait loop with Docker healthcheck

[numericals-org]

Closes #12322

Summary

Replaces the manual Postgres polling loop in docker/ol-home-start.sh with Docker's native healthcheck and depends_on mechanism.

Changes

• Added healthcheck to the db service in compose.override.yaml using the pg_isready pattern
• Updated depends_on in the home service in compose.override.yaml to use condition: service_healthy for the db service
• Removed the until pg_isready --host db; do sleep 5; done polling loop from docker/ol-home-start.sh (lines 8–9)
• Did not touch Solr-related changes to avoid conflicts with make home wait for solr in compose.override.yaml #12321

Testing

Run docker compose up and verify the home service starts only after Postgres is healthy, without the manual polling loop.

Screenshots

Checklist

• healthcheck added to db service using pg_isready in compose.override.yaml
• home service depends_on updated with condition: service_healthy for db
• Postgres wait loop removed from docker/ol-home-start.sh

[Copilot]

Pull request overview

This PR simplifies local dev startup by replacing the ol-home-start.sh Postgres polling loop with Docker Compose-native gating: a db healthcheck plus home.depends_on conditioned on service_healthy.

Changes:

• Add a Postgres healthcheck to db in compose.override.yaml using pg_isready.
• Update home to wait for db to be healthy via depends_on: condition: service_healthy.
• Remove the manual Postgres wait loop from docker/ol-home-start.sh.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
docker/ol-home-start.sh	Removes the manual Postgres readiness polling loop from the home startup script.
compose.override.yaml	Adds a db healthcheck and makes home depend on db health (similar to existing solr gating).

[Copilot]

The db healthcheck has no start_period (or similar startup grace period). With interval: 5s and retries: 5, a first-run init (or slow disk) can mark the container unhealthy very quickly, which can be confusing and can delay depends_on: condition: service_healthy until the health status recovers. Consider adding a start_period (and/or increasing retries) to better match Postgres startup times during initialization.

Suggested change

	interval: 5s
	interval: 5s
	start_period: 30s

[Copilot]

The healthcheck uses pg_isready -U postgres without -h. That checks the local Unix socket inside the db container, but other services connect over TCP via the db hostname. To make the healthcheck reflect the actual connection path, consider specifying -h localhost (and optionally -p 5432) and using the configured $${POSTGRES_USER} / $${POSTGRES_DB} rather than hardcoding postgres.

Suggested change

	test: ["CMD-SHELL", "pg_isready -U postgres"]
	test: ["CMD-SHELL", "pg_isready -h localhost -p 5432 -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]

[mekarpeles]

Thanks for the PR!

🤖 Copilot has been assigned for an initial review.

The linked issue (#12322) hasn't been triaged yet — priority assignment typically happens on Mondays and Fridays. The PR is currently assigned to @RayBB who has 12 PRs ahead of this one.

Possible improvements for this PR

• Commit history contains unrelated commits — two commits appear to be from a different branch: "google signup screen issue fix with use of ResizeObserver" and its revert. These are unrelated to this Docker healthcheck change and add noise to the PR history. Consider cleaning up your branch by squashing or rebasing before review. See the git cheatsheet for tips.

PR triage checklist (maintainers / Pam)

• PR description — not empty; explains what the change does and how to verify it
• References an issue — PR body contains a #NNN reference
  • Linked issue is triaged — has a Priority: * label (not just Needs: Triage)
  • Linked issue is assigned — has at least one assignee
• Commit history clean — no WIP/fixup/conflict noise; commit messages are meaningful
• CI passing — no failing check-runs
• Test cases present — if the change touches substantive logic, test coverage exists or is explained
• Proof of testing — PR body includes a description of what was tested, a screenshot, or a video

Note

This comment was automatically generated by Pam, Open Library's Project AI Manager, on behalf of @mekarpeles. Pam is designed to provide status visibility, perform basic project management functions and relevant codebase research, and provide actionable feedback so contributors aren't left waiting.

[RayBB]

Excellent work here. This is doing just what we expected.
I think we're gonna have a much more resilient dev environment thanks to this!

I did push up a few changes to the timing so that we check quicker. I encourage you to look into the commit if you'd like to learn more.

Cheers!