Election Safety

The property: at most one leader per term. Everything else in Raft leans on it.

What breaks without it: two leaders in the same term both accept client writes, both replicate, and two different commands land at the same log index on different nodes. Each leader counts its own majority, marks its entry committed, and replies OK to its client. Now x=5 is "committed" on one side of the cluster and x=9 on the other — split-brain with receipts. There is no repair step; the guarantee was already broken the moment both clients got acks.

Why Raft's rules make it impossible

Two ingredients:

1. A node votes for at most one candidate per term (voted_for, persisted).
2. Winning requires a strict majority — more than n/2 votes, the candidate's self-vote included.

Any two majorities of the same cluster overlap in at least one node. If candidates A and B both claimed term-5 majorities, some node voted for both in term 5 — impossible by ingredient 1:

5 nodes, majority = 3
A's voters: {n1, n2, n3}
B's voters: {n3, n4, n5}
            n3 voted twice in one term -> contradiction

It is a two-line proof, which is why it survives every crash/partition scenario you can invent.

What actually protects committed data

Beware a common mis-statement: one node holding an entry does NOT stop a stale candidate from winning — that node simply votes NO and can be outvoted by the rest. The real guarantee (Leader Completeness) is about committed entries: committed means replicated on a majority; a winner needs a majority of votes; the two sets must intersect, and the intersecting voter's up-to-date check (last lesson) refuses any candidate whose log is behind its own. Hence every future leader provably holds every committed entry. Uncommitted entries get no such protection — they can be legally discarded, which is exactly why the client's ack waits for commit.

Elections under real failures

• Minority partition: can never elect — no quorum. Its candidates churn: timeout, term+1, lose, repeat, so their current_term climbs while the majority side keeps serving. On heal, the inflated term forces the legitimate leader to step down (higher term wins), triggering one gratuitous re-election that an up-to-date node then wins. Disruptive, never unsafe — the PreVote extension (wrap-up lesson) removes even the disruption.
• Split vote: two followers time out together, each takes its self-vote plus a slice of the rest, neither reaches majority. Only liveness suffers; the term ends leaderless and randomized timeouts de-collide the retry.

Your simulation mirrors the bookkeeping: each TIMEOUT starts a fresh election in a new term, and votes cast for a previous election's candidate must not count toward the current one.

Your exercise

Compute election outcomes. Majority is strict — more than n/2, counting the candidate's self-vote. The grader-caught mistakes: with NODES 3, a single VOTE 2 1 already makes RESULT print node 1 (self + 1 = 2 of 3); a one-node cluster elects itself, printing node 1; and after TIMEOUT 1 then TIMEOUT 2, a VOTE 3 1 belongs to a dead election — RESULT prints NO_LEADER. Before any timeout at all, RESULT is also NO_LEADER.