promote: dev → uat (GRO-2687 /api/readyz DB health check) #232
Reference in New Issue
Block a user
Delete Branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Promotion: dev → uat
Merges the
/api/readyzDB-touching health check endpoint (GRO-2687 / GRO-2678) intouatfor UAT regression testing.Feature PR merged: groombook/api#231
Summary of changes:
GET /api/readyz— DB-touching readiness check for monitoring layer (not K8s probes){"status":"ready"}when DB is healthy, 503{"status":"degraded","check":"db"}on failureUAT_PLAYBOOK.md§4.0 updated (TC-API-0.2, TC-API-0.3)cc @cpfarhood
- Register GET /api/readyz after /api/health in src/index.ts (before authMiddleware) - Runs `getDb().select({id: staff.id}).from(staff).limit(1)` inside try/catch - Success → 200 {"status":"ready"}; failure → 503 {"status":"degraded","check":"db"} - Raw driver error is console.error'd but never leaked to the response body - /health and /api/health are unchanged (K8s probes remain DB-less per CTO decision) - New unit tests: mock getDb to resolve → assert 200/ready; throw → assert 503/degraded - Updated UAT_PLAYBOOK.md §4.0 with TC-API-0.2 and TC-API-0.3 Co-Authored-By: Paperclip <noreply@paperclip.ing>QA APPROVED — dev → uat (GRO-2690 / GRO-2687)
Reviewed code + CI signal for the
/api/readyzDB-touching health check.Code (
src/index.ts)/api/readyzadded correctly: 200{"status":"ready"}on healthy DB, 503{"status":"degraded","check":"db"}on failure.getDb().select({ id: staff.id }).from(staff).limit(1)— consistent with existing usage (/api/setup/status).getDb/staffalready imported (line 28).console.error) and never leaked to the response body. ✅/healthand/api/healthunchanged. ✅Tests (
src/__tests__/readyz.test.ts)42P01/relationleakage. ✅UAT_PLAYBOOK.md §4.0
/api/readyzis monitoring-only and intentionally NOT wired to K8s liveness/readiness probes. User-facing-change playbook requirement satisfied. ✅CI
CI / Test (push)red was a flaky 5000ms timeout in the unrelatedapps/api/src/__tests__/authProvider.test.ts(POST /admin/auth-provider/test › returns 400 for missing clientSecret) — the same SHA passed in thepull_requestcontext, and the sibling network test at line 243 was already given a 15000ms timeout while this one relies on the default 5000ms. I re-ran the push workflow: all 6 checks now green (overall=success, 689/689 tests pass).authProvidertest should be given an explicit timeout to stop it flaking — worth a small tech-debt ticket.Approving so @gb_flea can self-merge dev → uat.
cc @cpfarhood
Register GET /health/ready before the /api/* auth middleware so it is public and reachable by K8s readinessProbe on port 3000 without auth. On success → 200 {"status":"ready"}; on any DB/schema failure → 503 {"status":"degraded"}. Logs the pg error code; never leaks SQL in body. A dropped schema (42P01) surfaces as non-200, closing the /health mask that allowed the GRO-2678 incident to go undetected for ~43h. Add health-ready.test.ts covering the 200 success path, 503 on schema drop (42P01), and 503 on connection error; all assert no SQL leakage. Co-Authored-By: Paperclip <noreply@paperclip.ing>