bitflicker64 commented on PR #3185: URL: https://github.com/apache/hugegraph/pull/3185#issuecomment-5550666000
Fixed in a3b9395, taking the callback approach from the end-to-end report above. `RaftStateMachine` keeps a volatile copy of the last announced state and leader visibility, written by `onLeaderStart`, `onLeaderStop`, `onStartFollowing`, `onStopFollowing`, `onError` and `onShutdown`, and `getRaftStatus()`, `hasLeader()` and all three gauges read only that copy. The probe path no longer touches the raft node at all; the unit tests pin that with `verifyNoInteractions` on the node mock. Reproduced the stall shape locally before pushing: a PD electing against two blackholed peers, so every reconnect hangs the way connects to deleted pods do. 15 consecutive `/v1/ready` samples during the perpetual election all answered `503` in under 21 ms (the K8s run measured 9.79 s on the same path), a `/actuator/prometheus` scrape took 51 ms, and the healthy single-node answer stays at about 2 ms. Two behaviour notes. `state` is now the last role raft announced, so a candidate reports `STATE_FOLLOWER` with `"ready": false` (jraft has no candidacy callback), and a node that has never joined a quorum reports `STATE_UNINITIALIZED`; the docs say so. And `hg_raft_leader` now reflects the term flag rather than `isLeader(true)`, so it can lag a partitioned stale leader by up to the lease window, in exchange for scrapes that never block. Production callers of `RaftEngine.isLeader()` are untouched. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
