Files
health/CHANGELOG.md
Rene Nochebuena e1b6b7ddd7 feat(health): initial stable release v0.9.0
HTTP health check handler with parallel goroutine-per-check execution, 5 s request-derived timeout, and two-level criticality (LevelCritical → 503, LevelDegraded → 200).

What's included:
- `Checkable` interface (HealthCheck / Name / Priority) and `Level` type with LevelCritical and LevelDegraded constants
- `NewHandler(logger, checks...)` returning http.Handler; runs all checks concurrently via buffered channel, returns JSON with per-component status and latency
- `ComponentStatus` and `Response` types for the JSON response body

Tested-via: todo-api POC integration
Reviewed-against: docs/adr/
2026-03-18 14:06:17 -06:00

2.9 KiB

Changelog

All notable changes to this module will be documented in this file.

The format is based on Keep a Changelog, and this module adheres to Semantic Versioning.

0.9.0 - 2026-03-18

Added

  • Level type — int representing component criticality; zero value is LevelCritical
  • LevelCritical constant (value 0) — a failing critical component sets overall status to DOWN and returns HTTP 503
  • LevelDegraded constant (value 1) — a failing degraded component sets overall status to DEGRADED and returns HTTP 200
  • Checkable interface — HealthCheck(ctx context.Context) error, Name() string, Priority() Level; implemented by infrastructure components
  • Logger interface — duck-typed minimal logger (Debug, Info, Warn, Error, WithContext) satisfied by logz.Logger without importing logz
  • ComponentStatus struct — JSON-serialisable per-component result with fields status string, latency string (omitempty), and error string (omitempty)
  • Response struct — JSON-serialisable overall response with fields status string and components map[string]ComponentStatus
  • NewHandler(logger Logger, checks ...Checkable) http.Handler — constructs an http.Handler that runs all registered checks concurrently, collects results via a buffered channel, and writes a JSON Response
  • Parallel check execution: each Checkable.HealthCheck call runs in its own goroutine; a buffered channel sized to the check count prevents goroutine leaks
  • Per-request 5-second deadline derived from context.WithTimeout(r.Context(), 5*time.Second) and propagated to all check goroutines
  • Overall status aggregation: UP if all checks pass; DEGRADED (HTTP 200) if at least one degraded component fails and no critical component fails; DOWN (HTTP 503) if any critical component fails
  • Check latency measurement: each goroutine records time.Since(start) and includes it as a string in ComponentStatus
  • Content-Type: application/json response header set on every response

Design Notes

  • All checks run in parallel goroutines and report through a buffered channel; the buffer is sized exactly to the number of registered checks at construction time, so the handler is guaranteed to drain all results without blocking even if it returns early.
  • The two-level criticality model (LevelCritical / LevelDegraded) gives orchestrators and load balancers a clean binary HTTP signal (200 vs 503) while still surfacing partial degradation in the JSON body for monitoring systems.
  • The Logger and Checkable interfaces are defined entirely within this package using duck typing — no micro-lib module is imported, keeping health a pure stdlib package (Tier 0/1) that infra packages can satisfy without a circular dependency.