Make Postgres wait timeout configurable

[NumericalAdvantage]

Summary

• Replace hard-coded wait-for-it timeouts with configurable WAIT_POSTGRES_TIMEOUT environment variable across all docker-compose files
• Default is 180 seconds, overridable via .env

See also openradx/radis#212

Test plan

• Verify docker compose config correctly interpolates the default (180s) when WAIT_POSTGRES_TIMEOUT is unset
• Verify setting WAIT_POSTGRES_TIMEOUT=300 in .env overrides all wait-for-it calls

Summary by CodeRabbit

• Chores
  • Improved application startup configuration with parameterized database readiness timeout across development and production environments, enabling deployment customization to accommodate varying database initialization speeds and environment-specific requirements.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 53061adc-8a03-4c42-9870-90e98bf08d7e

📥 Commits

Reviewing files that changed from the base of the PR and between 929cea2 and 7765e08.

📒 Files selected for processing (2)

• docker-compose.dev.yml
• docker-compose.prod.yml

---

📝 Walkthrough

Walkthrough

Updated docker-compose configuration files to replace hardcoded Postgres readiness timeout values with parameterized environment variables. The wait-for-it Postgres timeout was changed from 60 seconds to ${WAIT_POSTGRES_TIMEOUT:-180} (default 180 seconds) across multiple services in both development and production configurations.

Changes

Cohort / File(s)	Summary
Docker Compose Configuration docker-compose.dev.yml, docker-compose.prod.yml	Parameterized Postgres readiness timeout from hardcoded 60 seconds to configurable ${WAIT_POSTGRES_TIMEOUT:-180} in web/init, default_worker, and dicom_worker services.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 With Docker's patience newfound in hand,
Timeouts now dance to a gentle command.
One hundred eighty seconds, or less if you say—
The rabbit configs grow flexi-bel today! 🥕

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Make Postgres wait timeout configurable' directly and clearly summarizes the main change: parameterizing the hardcoded Postgres timeout with an environment variable across docker-compose files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch configurable-postgres-wait-timeout

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request replaces the hardcoded 60-second timeout for PostgreSQL availability with a configurable WAIT_POSTGRES_TIMEOUT environment variable, defaulting to 180 seconds, across development and production Docker Compose files. The reviewer suggests documenting this new variable in example.env to maintain consistency with project standards. Additionally, there is a concern regarding a potential timeout conflict with the web service's 300-second wait period if the new Postgres timeout is configured too high.

[gemini-code-assist]

The new WAIT_POSTGRES_TIMEOUT environment variable should be added to example.env with its default value (180). This ensures the configuration option is discoverable for users and documented in the standard environment template, following the repository's convention for key variables.

References

1. Key environment variables should be documented in example.env. ^(link)

[gemini-code-assist]

There is a potential timeout dependency issue. The web service (line 48) has a hardcoded 300-second timeout waiting for this init service. If WAIT_POSTGRES_TIMEOUT is set to a value close to or greater than 300, the web service will likely time out before init can complete its own wait for Postgres and subsequent migrations. It is recommended to also make the web service's wait timeout configurable or ensure it is always greater than the Postgres timeout to avoid race conditions during slow startups.