psa-systems/mokosh-server
Watch
9
0
Fork
You've already forked mokosh-server
 1
Code Issues Pull requests Projects Releases 10 Packages Wiki Activity Actions

fix(ready): bound the readiness DB ping at 3s #469

Merged
David merged 1 commit from fix/pms-685-readiness-db-ping-timeout into main 2026-08-01 00:58:43 +02:00
Conversation 0 Commits 1 Files changed 2 +88 -5
Claude-Run commented 2026-08-01 00:51:37 +02:00
Member
Copy link

The readiness DB ping was unbounded, so a wedged connection could hold /api/v1/ready open past whatever timeout the orchestrator applies, and there was no documented budget for how slow a healthy SELECT 1 may be. Wrap it in a documented 3s bound: a cold pool or a loaded Postgres answers in ~1s and must still read as ready, while a truly unreachable database still fails the probe (now with error: db ping exceeded 3s instead of hanging). The ping future is passed to bounded_db_ping rather than the pool so the timeout path is unit testable on the virtual clock.

tests/readiness.rs was also environment-dependent: just test-integration runs inside the dev compose server container, which always exports INFISICAL_BASE_URL while the infisical service is an opt-in profile. The best-effort Infisical probe then failed against an absent host and the handler returned 503 after its 1s timeout (latency=1001 ms), which is what a probe run there looked like. Each /ready case now clears the variable before booting, so the suite's stated premise (Infisical unconfigured) holds regardless of the surrounding shell, single- or multi-threaded.

#PMS-685

The readiness DB ping was unbounded, so a wedged connection could hold /api/v1/ready open past whatever timeout the orchestrator applies, and there was no documented budget for how slow a healthy `SELECT 1` may be. Wrap it in a documented 3s bound: a cold pool or a loaded Postgres answers in ~1s and must still read as ready, while a truly unreachable database still fails the probe (now with `error: db ping exceeded 3s` instead of hanging). The ping future is passed to `bounded_db_ping` rather than the pool so the timeout path is unit testable on the virtual clock. `tests/readiness.rs` was also environment-dependent: `just test-integration` runs inside the dev compose `server` container, which always exports INFISICAL_BASE_URL while the `infisical` service is an opt-in profile. The best-effort Infisical probe then failed against an absent host and the handler returned 503 after its 1s timeout (`latency=1001 ms`), which is what a probe run there looked like. Each /ready case now clears the variable before booting, so the suite's stated premise (Infisical unconfigured) holds regardless of the surrounding shell, single- or multi-threaded. #PMS-685
fix(ready): bound the readiness DB ping at 3s
All checks were successful
E2E / Playwright against staging (pull_request) Successful in 45s
Details
Check / fmt + clippy + build + tests (pull_request) Successful in 3m5s
Details
Create release / Gate (release-branch merges only) (pull_request) Successful in 2s
Details
Create release / Create release from merged PR (pull_request) Has been skipped
Details
Integration / integration tests (pull_request) Successful in 10m20s
Details
6bbda8ee5d 
The readiness DB ping was unbounded, so a wedged connection could hold /api/v1/ready open past whatever timeout the orchestrator applies, and there was no documented budget for how slow a healthy `SELECT 1` may be. Wrap it in a documented 3s bound: a cold pool or a loaded Postgres answers in ~1s and must still read as ready, while a truly unreachable database still fails the probe (now with `error: db ping exceeded 3s` instead of hanging). The ping future is passed to `bounded_db_ping` rather than the pool so the timeout path is unit testable on the virtual clock.

`tests/readiness.rs` was also environment-dependent: `just test-integration` runs inside the dev compose `server` container, which always exports INFISICAL_BASE_URL while the `infisical` service is an opt-in profile. The best-effort Infisical probe then failed against an absent host and the handler returned 503 after its 1s timeout (`latency=1001 ms`), which is what a probe run there looked like. Each /ready case now clears the variable before booting, so the suite's stated premise (Infisical unconfigured) holds regardless of the surrounding shell, single- or multi-threaded.

#PMS-685
David merged commit 6dce6ab706 into main 2026-08-01 00:58:43 +02:00
David deleted branch fix/pms-685-readiness-db-ping-timeout 2026-08-01 00:58:43 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/mokosh-server!469
No description provided.