#935 `osctrl-tls`: health endpoint reports backend degradation via `HTTP 204` Pull request opened by javuto osctrl-tls: health endpoint reports backend degradation via HTTP 204 Problem The

/health

endpoint on

osctrl-tls

always returned HTTP 200, even when the DB health monitor (added in

resistant-backend-outage-tls

) had flipped the service into stale-serve mode. Operators and load balancers had no way to distinguish a healthy

osctrl-tls

from one that was serving cached data because the backend was down. Change

HealthHandler

now consults the wired

backend.DegradedReader

and returns HTTP 204 (no body) when the backend is degraded, instead of always returning 200. When no monitor is wired (or it reports healthy), the legacy 200 + "✅" body is unchanged. •

cmd/tls/handlers/get.go

—

HealthHandler

checks `h.DBHealth.IsDegraded()`; on true it writes 204 and returns, otherwise the previous 200 path runs. •

cmd/tls/handlers/handlers.go

— Added a

DBHealth backend.DegradedReader

field to

HandlersTLS

and a

WithDBHealth

option. •

cmd/tls/main.go

— Wired

handlers.WithDBHealth(dbHealth)

at handler construction.

dbHealth

is

nil

when

--db-health-check

is disabled, so the field's nil check preserves the legacy behavior automatically. •

cmd/tls/handlers/get_test.go

— Added

TestHealthHandlerDegraded

(asserts 204 + empty body) and

TestHealthHandlerDegradedReaderNil

(asserts the nil-monitor path still returns 200 + "✅"). Why 204 and not 503 The service is still serving osquery nodes from stale-serve caches — that is the whole point of the canary added in the TLS branch. Returning 503 would make load balancers drop traffic to a service that is intentionally still handling requests, defeating the outage resistance. 204 signals "degraded but alive" so operators/LBs can distinguish the state without failing the health check. Validation •

go build ./cmd/tls/...

— clean •

go vet ./cmd/tls/... ./cmd/api/...

— clean •

go test ./cmd/tls/handlers/

— passes, including the two new tests jmpsec/osctrl