08 - Form Specifications (Health Module)
- 1. Retry action (S1)
(proposed) - 2. Poll cadence input (S1, internal)
(proposed) - 3. Explicitly not built
(proposed)/(planned) - 4. Validation notes
The Health module has no data-entry forms. This file documents the only interactive input (Retry) and the
(proposed)configuration surface that is deliberately not built. Backend has no DTOs: the endpoint takes no body, query or params (health.controller.ts:27-37- bare@Get()+check()).
1. Retry action (S1) (proposed)
Not a form - a single async action button:
| Aspect | Spec |
|---|---|
| Trigger | tap Retry |
| Behavior | immediate single GET /api/v1/health; on success, resets the poll timer (skip next tick, 13 §2) |
| Guard | disabled while a fetch is in flight; disabled during 429 countdown (rate-limit.constants.ts:4 - 30 req/min shared with all clients of the endpoint) |
| Result | state swap per 06 S1 rows 2-4; no snackbar on success (the screen IS the result); error → offline banner |
| Semantics | Button('Retry'); announce result via banner live region |
Rate-limit math (client must respect it): poll every 30 s + manual retries must stay under 30 req/min for the whole deployment - the endpoint is public and shared with LBs (02 §1). Client-only guidance: never auto-retry a 503 in a loop; 429 → back off ≥ 60 s (14 QA-5).
2. Poll cadence input (S1, internal) (proposed)
Internal, not user-facing: poll interval fixed at 30 s foreground (13 §2). No settings screen, no user-editable interval - YAGNI; the endpoint rate cap is the constraint that makes user-configurable intervals an abuse vector, not a feature.
3. Explicitly not built (proposed) / (planned)
| Surface | Status | Why not |
|---|---|---|
| Health "thresholds" form (alert when redis down, etc.) | (proposed) | no server config; alerting out of module scope (01 §5) |
| Dependency detail form (DB name, queue picker) | (proposed) | nothing user-writable; endpoint fixed 4 indicators (health.controller.ts:31-36) |
| Liveness/readiness toggle (which probes /live runs) | (planned) | split endpoints not implemented (docs/user-flows/END_TO_END_USER_FLOWS.md:738-740); server-side concern anyway |
4. Validation notes
No text inputs → no client validation rules, no keyboard types, no autofill,
no submit semantics. If a future (proposed) config form ever lands, it must
validate client-side before submit and map server 400 details
(http-exception.filter.ts:103-108); until then: nothing to validate.