prisma-risk / tsoracle / 26374976709

95%

Build Type

push

github

Committed by web-flow

Commit Message

refactor(server): emit leader-transition counter after state changes in run_leader_watch (#328)

The `tsoracle.leader_transition.total` counter was incremented before the
`match evt` in `run_leader_watch`, so every branch (Leader/Follower/Unknown)
waited behind the metric emission before clearing the allocator and publishing
the new `ServingState`. Under the `metrics` crate's de facto non-blocking O(1)
recorder contract this is unobservable, but it makes "metrics latency =
correctness latency" a structural property: a recorder with a blocking
`increment` would delay safety-critical leadership transitions.

Move the counter into each match arm, emitted after that arm's safety state
change. The Leader arm counts after the up-front clear-to-NotServing (not on
the fence's success path) so a Leader event still increments exactly once even
when the fence steps down or faults, matching the prior pre-`match` behavior.
The fence_latency histogram is unchanged: it already records inside the Ok arm
after Serving is published, which its "fence-start to Serving" semantic
requires. No behavior change under any standard recorder.

Closes #79

Coverage Stats

9 of 9 new or added lines in 1 file covered. (100.0%)

1 existing line in 1 file now uncovered.

11418 of 12035 relevant lines covered (94.87%)

476079.51 hits per line