Add unit coverage for /healthz responses
Context
While wiring the health endpoint into a load balancer, I realized we have no tests covering the /healthz JSON/status behavior. A regression here could cause false positives or hide real outages.
Problem
The health handler assembles status and component fields (db/rpc), but success and failure paths aren’t tested. We could accidentally change the shape or status codes without noticing.
Expected behavior
/healthz should return 200 with "ok" statuses when both checks pass. If either check fails, it should return 503 and mark the failing component as "fail" while keeping the JSON shape stable.
Scope / non-goals
Don’t change handler logic beyond test coverage; keep the response fields stable.
Acceptance criteria
Hints
Use httptest in internal/health to stub checkers. Run go test ./internal/health.
Add unit coverage for /healthz responses
Context
While wiring the health endpoint into a load balancer, I realized we have no tests covering the
/healthzJSON/status behavior. A regression here could cause false positives or hide real outages.Problem
The health handler assembles status and component fields (db/rpc), but success and failure paths aren’t tested. We could accidentally change the shape or status codes without noticing.
Expected behavior
/healthzshould return 200 with "ok" statuses when both checks pass. If either check fails, it should return 503 and mark the failing component as "fail" while keeping the JSON shape stable.Scope / non-goals
Don’t change handler logic beyond test coverage; keep the response fields stable.
Acceptance criteria
status,db, andrpckeys when provided.Hints
Use
httptestininternal/healthto stub checkers. Rungo test ./internal/health.