pub fn set_sink_slot(slot: u32)Expand description
Record the outcome of resolution. A VALID slot latches for the life of the service; a MISS does NOT.
It used to latch either way, on the reading that u32::MAX means “this service holds no events
send cap” - a permanent fact deserving a permanent answer. It is not permanent. It also happens
when the sink is simply mid-restart at the instant of this service’s FIRST emission, and chaos
restarts the sink constantly. A service unlucky in that window then returned early on every
subsequent emission forever: it never sent, so it never saw a send failure, so it never reached the
reacquire path that exists precisely to recover from a restarted sink.
The damage would be silent and permanent, invisible except as a missing row - which is the one
thing msgs.received exists to rule out, since a service with no row is indistinguishable from a
dead one.
HONESTY ABOUT WHAT THIS DID AND DID NOT FIX. This was written while chasing a T630 run where fs
published six metric rows before a chaos storm and none afterwards, and the latch looked like the
cause. It was not: events restarted 0.5 s BEFORE fs there, so fs resolved successfully and
never latched at all. That run was the capless-publisher bug (metric/trace_emit never ASKING
for a cap) on top of the kernel dropping the peer declaration. This change stands on its own
merits - a permanent answer to a transient condition is wrong however rarely it fires - but it is
not the fix that closed that failure, and saying otherwise would leave the next reader chasing a
cause that was already ruled out.