pub struct ModuleHealthStatus {
pub status: SupervisorHealthStatus,
pub last_probe_ms: Option<u64>,
pub detail: Option<String>,
pub metrics: Option<Value>,
pub consecutive_failures: u32,
pub late_answer_count: u64,
pub last_late_answer_latency_ms: Option<u64>,
pub last_action: Option<String>,
pub last_action_ms: Option<u64>,
}Expand description
The supervisor’s view of one module’s health, relayed to clients over
channel-0 and rendered by ck health.
THIS TYPE IS WHERE THE ABSENCE MEANINGS ARE CREATED, which is why they are
stated here rather than only at the wire type a consumer reads. A reader can
look up what None means; only a writer can silently change it, and the
writer has no reason to go looking at a downstream contract before editing.
last_probe_ms: None MEANS NEVER PROBED, not probed-long-ago. It is cleared
back to None on re-registration precisely so a respawned module does not
carry its predecessor’s timestamp — so an old value and an absent one call for
opposite readings, and anything that defaulted this to a number would make a
never-probed module indistinguishable from one probed at the epoch.
detail and metrics are None when the module published none on this
probe, which does not mean it reported nothing wrong — it is also the shape
when the probe never reached it. last_probe_ms is what separates those.
Fields§
§status: SupervisorHealthStatus§last_probe_ms: Option<u64>§detail: Option<String>§metrics: Option<Value>§consecutive_failures: u32§late_answer_count: u64Number of replies received after a recurring health probe’s deadline. Unlike a timeout, every increment proves the module was alive.
last_late_answer_latency_ms: Option<u64>End-to-end latency of the newest late reply, measured from probe start.
last_action: Option<String>§last_action_ms: Option<u64>Set together with last_action; the pair moves as one, and both being
absent means no escalation has ever been taken rather than that the last
one succeeded.