Expand description
What /readyz reports about the backends it depends on.
The server probes the storage backend and the vector store in the
background and publishes a ReadinessSnapshot through a
tokio::sync::watch channel; the route reads the latest value and never
probes anything itself, so a flood of readiness requests costs the backends
nothing. The event backend is not part of the snapshot: its readiness is a
connection-state read the route makes inline (D55).
A backend’s own error message never reaches the response. The route is
unauthenticated, and a client error can quote an endpoint or a
credential-bearing URL, so a check reports one of a fixed set of
Unready reasons and the server logs the detail once per transition.
Readiness is about the backend, not the data in it: a probe that the
backend answered with “not found” leaves the replica ready, because it is
up and every other knowledge base keeps serving. The check still says so
(degraded, not_found), for the operator who deleted a bucket.
One check is not probed at all. On the s3 backend the server asks each bucket
once, at startup, whether it enforces the preconditions on a conditional PUT
(D70); a deployment that chose to run on one that does not is reported
degraded (preconditions_not_enforced) for as long as the process lives.
Structs§
- Check
- One backend’s latest probe.
- Readiness
Snapshot - The latest probe of every backend the poller covers.
Enums§
- Unready
- Why a check is not
ok. Closed set: the response body can say nothing else about a failure.
Type Aliases§
- Readiness
Receiver - The route’s end of the channel the poller publishes on.