Expand description
The detector port: what a layer above a failure detector may depend on, and the whole of it.
Two detectors exist now — crate::perfect_failure_detector and
crate::eventually_perfect_failure_detector — and Ω is written against whichever it is given.
That is the second consumer CLAUDE.md constraint 4 asks for before a port is extracted, and
the reason this module did not exist while there was only one.
§Why the vocabulary is not pinned to one pair of types
The same argument crate::link makes. Pinning Ind = pfd::Ind admits the perfect detector
and rejects ◇P, whose Ind has a second variant — and admitting both is the entire point,
because a leader detector written against one cannot compose over the other. So a detector keeps
its own Ind, and the port supplies the one translation a layer above needs: is this a
suspicion, or the withdrawal of one?
§A detector that never retracts says so by never producing a withdrawal
P classifies its Crash as DetectorInd::Suspect and never yields
DetectorInd::Restore — not because a flag says so, but because it has no indication that
could become one. docs/scope-annotated-modules.md forbids a module declaring what it cannot
observe, and this is that rule applied to a detector: a layer above handles both arms, and over
P the second is unreachable rather than merely unused.
There is deliberately no RetractingDetector marker trait. link.rs records at length what
happened to ScopedLink — introduced for a bound nothing could take, deleted for want of a
consumer — and the same would be true here. Ω needs no such bound: it handles a withdrawal if one
comes and is correct if none ever does.
Enums§
- Detector
Ind - A detector’s indication, in the port’s terms.
Traits§
- Detector
- What a layer above a failure detector may depend on.
- Volatile
Detector - A detector that keeps nothing durable the layer above has to know about.