Raft elections: terms, durable votes, and log eligibility

A follower that starts an election advances its current term, becomes a candidate, votes for itself, and requests votes. Each server grants at most one candidate its vote in a given term, retaining the decision across crashes. A candidate becomes leader only after obtaining the required majority for that same term. Duplicate replies do not create extra voters, and a delayed grant from an older term cannot be counted toward the current election. Node identity and the configured voter set define what a distinct vote means.

On observing a valid higher term, a server updates its term and follows the protocol's transition to follower. A disconnected old leader can nevertheless continue to believe it is leader until it learns newer information. The invariant is not that only one process anywhere ever has the leader role at a moment. It is that at most one candidate can obtain a valid majority for a particular term, because intersecting majorities cannot share a server that votes twice in that term. Persisting votes is therefore a safety requirement, not an optional recovery optimization.

One leader per term is insufficient if a later leader can omit committed entries. Raft therefore compares the candidate's last log term and index with the voter's pair. A later last-entry term is considered more up-to-date; only when those terms match does the larger last index win. A candidate with a more recent last-entry term can be eligible even with a shorter log. The comparison belongs to the complete log-matching and commitment proof; it is not an arbitrary preference for shorter or longer files.

The term in an election request and the term of the candidate's last log entry are different fields. A candidate starting election term twelve might have last created entries from term nine. Raising the election term does not fabricate a term-twelve log entry or repair missing history. Before granting, a voter checks both its vote availability in the request's term and the log eligibility condition. Skipping the log check can elect a candidate that discards prior committed commands despite an apparently well-formed majority election.

Randomized election delays reduce repeated split votes when message delivery and processing become timely enough. Choose timeouts with realistic network, scheduling, and disk delays in mind; a busy event loop can look like a failed leader. No particular timeout makes a crash inference infallible. Increasing a timeout changes responsiveness and instability tradeoffs, while weakening vote persistence or accepting stale-term messages changes correctness. Separate those changes during diagnosis rather than treating every election failure as a reason to bypass the protocol.

In the reliability lab, Reset and explicitly set n=5, k=2 before predicting and using Play or Step. Three available voters meet the numerical election threshold. For another run Reset and explicitly set n=5, k=3; two cannot. The illustration contains no candidate, term, vote history, log-eligibility check, or message delay. It cannot distinguish three eligible voters from three nodes that already voted for competing candidates. Use a separate per-term vote table to explain whether a particular candidate can actually win.