Rene Nochebuena
e1b6b7ddd7
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/
33 lines
2.9 KiB
Markdown
33 lines
2.9 KiB
Markdown
# Changelog
|
|
|
|
All notable changes to this module will be documented in this file.
|
|
|
|
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
|
and this module adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
|
|
## [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.
|
|
|
|
[0.9.0]: https://code.nochebuena.dev/go/health/releases/tag/v0.9.0
|