Follow-up to #170 (528+/67-). The PR added connect_db_with_retry, the degraded server, /ready's DB probe, is_likely_permanent_db_error, and the From<anyhow::Error> sqlx remap that makes the 503 arm reachable at all. The only test it added covers smart_http_repo_name (the .git helper, its smallest hunk).
Evidence (executed)
Mutating db_unavailable to always return false (a regression that re-buries the outage 503 as a 500) left 478/478 of #170's tests green; only a purpose-built guard caught it. So the PR's headline behavior (outage returns 503, not 500) has no reachable-503 test. Backoff math, shutdown-during-retry, and the degraded/full handoff are likewise untested (grep across src/ finds no test referencing connect_db_with_retry, database_retry_delay_secs, run_degraded_server, or is_likely_permanent_db_error).
Suggested tests (each cheaply constructible; all verified to run during the audit)
into_response boundary: AppError::Db(Io|PoolTimedOut) -> 503 + db_unavailable; a non-connection sqlx error (e.g. RowNotFound) -> 500. The negative case proves db_unavailable() did not over-widen./health stays 200 while /ready returns 503 against a state whose ping() fails (test_state_lazy already points at a dead DB). This also guards the peer-routing gap in the sibling issue.database_retry_delay_secs: >= 1 (no busy-spin), <= max (clamps), no overflow across the attempt range including u64::MAX.connect_db_with_retry: returns None promptly on shutdown (not after the full backoff), and keeps retrying (never returns) during a persistent outage.
These would lock down the resilience behavior #170 delivers and guard the two sibling follow-ups.
Follow-up to #170 (528+/67-). The PR added
connect_db_with_retry, the degraded server,/ready's DB probe,is_likely_permanent_db_error, and theFrom<anyhow::Error>sqlx remap that makes the 503 arm reachable at all. The only test it added coverssmart_http_repo_name(the.githelper, its smallest hunk).Evidence (executed)
Mutating
db_unavailableto always return false (a regression that re-buries the outage 503 as a 500) left 478/478 of #170's tests green; only a purpose-built guard caught it. So the PR's headline behavior (outage returns 503, not 500) has no reachable-503 test. Backoff math, shutdown-during-retry, and the degraded/full handoff are likewise untested (grep acrosssrc/finds no test referencingconnect_db_with_retry,database_retry_delay_secs,run_degraded_server, oris_likely_permanent_db_error).Suggested tests (each cheaply constructible; all verified to run during the audit)
into_responseboundary:AppError::Db(Io|PoolTimedOut)-> 503 +db_unavailable; a non-connection sqlx error (e.g.RowNotFound) -> 500. The negative case provesdb_unavailable()did not over-widen./healthstays 200 while/readyreturns 503 against a state whoseping()fails (test_state_lazyalready points at a dead DB). This also guards the peer-routing gap in the sibling issue.database_retry_delay_secs:>= 1(no busy-spin),<= max(clamps), no overflow across the attempt range includingu64::MAX.connect_db_with_retry: returnsNonepromptly on shutdown (not after the full backoff), and keeps retrying (never returns) during a persistent outage.These would lock down the resilience behavior #170 delivers and guard the two sibling follow-ups.