From 8d42bfffc9f2057dff690d38d4daee155921da76 Mon Sep 17 00:00:00 2001 From: Flea Flicker <22+gb_flea@noreply.git.farh.net> Date: Wed, 5 Aug 2026 08:22:00 +0000 Subject: [PATCH] test(GRO-2652): add boot resilience UAT test cases (TC-API-19.x) New section 4.19 verifies: - /health available before initAuth completes - auth routes return 503 (not crash) during init retry window - pod restart count stays stable after deploy - retry log lines emitted correctly - auth recovers after transient DB hiccup Co-Authored-By: Paperclip --- UAT_PLAYBOOK.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/UAT_PLAYBOOK.md b/UAT_PLAYBOOK.md index 60acc87..7b5f9d8 100644 --- a/UAT_PLAYBOOK.md +++ b/UAT_PLAYBOOK.md @@ -439,6 +439,22 @@ Both use the stops' stored `latitude`/`longitude` in `stopOrder`: **origin = fir | TC-API-18.10 | Groomer cannot export another's route | As groomer, export a route owned by a different groomer | 403 Forbidden (`groomers may only access their own route`) | | TC-API-18.11 | Receptionist denied | As **receptionist**, export any route | 403 Forbidden (role not permitted) | + +### 4.19 Boot Resilience — ECONNRESET Recovery (GRO-2652) + +Verifies the API process does not crash on transient boot-time DB connection resets and that auth routes degrade gracefully until initialization succeeds. + +| TC | Test Case | Steps | Expected Result | +|----|-----------|-------|-----------------| +| TC-API-19.1 | Health endpoint available before auth init | 1. Deploy the image (or restart the api pod)
2. `GET /health` immediately (within first 2 s of pod start) | 200 `{"status":"ok"}` — server accepts requests before `initAuth()` completes | +| TC-API-19.2 | Auth routes return 503 when auth not yet initialized | 1. Temporarily set `OIDC_ISSUER` to an unreachable host so `initAuth()` keeps retrying
2. `POST /api/auth/sign-in/email` during the retry window | 503 `{"error":"Authentication not configured"}` — process stays alive, does not exit | +| TC-API-19.3 | Pod does not crash on first-attempt DB reset | 1. Review pod restart count after normal deployment
2. Confirm `kubectl get pod -n groombook` shows `RESTARTS: 0` (or same as before deploy) for the new pod | No new restarts — ECONNRESET causes retry, not process exit | +| TC-API-19.4 | DB query retry log lines visible | After deploy, `kubectl logs -n groombook ` | If any DB retry occurred, log lines matching `[auth] DB query attempt N failed` are present; on clean boot no retry lines appear | +| TC-API-19.5 | Auth init retry log lines visible | When auth init fails and retries, check pod logs | Log lines matching `[auth] initAuth attempt N failed` present; process continues; no `process.exit` | +| TC-API-19.6 | Auth succeeds after transient DB hiccup | 1. Allow pod to retry until DB is available
2. `POST /api/auth/sign-in/email` with valid credentials after init succeeds | 200 with session cookie — auth recovers without pod restart | +| TC-API-19.7 | Normal sign-in still works end-to-end | Follow TC-WEB-SSO-3 (SSO sign-in) on UAT | Successful sign-in, staff list visible — no regression from resilience changes | +| TC-API-19.8 | Public routes unaffected during auth retry | While auth is retrying (TC-API-19.2 setup), `GET /api/branding` | 200 with branding data — public routes bypass auth and serve normally | + ## Pass/Fail Criteria **Pass:**