Decide pre-vote on the candidate's log, not on liveness alone

[tiandiwonder]

Problem

handle_prevote_req grants on liveness alone. It reads the candidate's last log index and term into its log line and then decides on hb_alive_ and nothing else. The real vote checks them:

// handle_vote_req
bool log_okay =
    req.get_last_log_term() > log_store_->last_entry()->get_term() ||
    ( req.get_last_log_term() == log_store_->last_entry()->get_term() &&
      log_store_->next_slot() - 1 <= req.get_last_log_idx() );

So pre-vote is weaker than the vote it stands in for, in the one dimension that decides the outcome. That inverts its purpose: pre-vote exists (Ongaro thesis §9.6) precisely so a node that would lose the real vote does not disturb the term first.

A member that cannot win still passes pre-vote during any leaderless window, bumps the term and deposes the sitting leader. Deposing the leader creates the next leaderless window, so the same hopeless candidate qualifies again — the disruption is self-sustaining.

Observed on a three-node ensemble with no network partition: 10 leadership changes in 32 minutes, terms 297 → 313, the decisive ones initiated by a member whose log index had not advanced by a single entry in 51 seconds. In the same window, 15 pre-vote requests from that member were correctly denied — with a leader alive hb_alive_ is true and the existing check is enough. Only the leaderless window is affected.

Fix

Compute log_okay the way handle_vote_req does and require it for the grant. The request already carries both fields, so this needs no protocol change.

• The is_catching_up() exemption is unchanged. Its comment explains that a catching-up server does not receive normal append_entries, so its own hb_alive_ may be stale — that concerns the voter's state, not the candidate's fitness.
• Liveness is preserved by the standard pre-vote argument: a candidate denied here would also have lost the real vote, since the voter applies the same predicate there. An election still succeeds as soon as a member whose log is fresh enough times out.
• The deny path now reports which of the two reasons applied. They were previously indistinguishable in exactly the situation where the difference matters.

Test

prevote_denies_candidate_whose_log_is_behind_test in tests/unit/leader_election_test.cxx: one member is put far enough behind to lose, the leader is taken away, and a second member times out as well — hb_alive_ on a follower is cleared only by that follower starting a pre-vote of its own, so without that step the denial comes from the heartbeat check and the test passes with or without this change. It then asserts the term does not move and that a member whose log is current still wins.

Reverting the change turns it red: s2.raftServer->get_term() expected 1, actual 2.

One behaviour change beyond the defect

The safety argument above — a candidate denied here would also have lost the real vote — holds at the instant of the denial, not necessarily a moment later. leader_election_priority_test is a case where it does not.

There, a resigning leader hands over to a higher-priority successor that is one entry behind: the entry the resigning leader appended on becoming leader, still uncommitted. Before this change pre-vote was granted on liveness alone, the successor caught up while the vote it then initiated was in flight, and the takeover completed in one round. Now it is denied and the takeover costs an extra election timeout.

That is a real cost on the priority-takeover path, and a conscious one: pre-vote must not be more permissive than the vote it predicts, and one extra round there is smaller than a self-sustaining election storm. Liveness still holds — the resigning leader appends nothing further, so the successor does not keep falling behind and wins on its next timeout.

The test therefore hands the successor that entry first. It uses delieverReqTo rather than execReqResp because the response half re-arms the resigning leader's hb_alive_, and clearing that flag on resign (raft_server.cxx:1508, "Clear live flag to avoid pre-vote rejection") is exactly what lets a successor's pre-vote through.

Full suite: 10/10 with the change. Removing the fix leaves only the new regression test red, so the sync did not weaken what the priority test checks.