Page History

...

We will add a new field PreVote to VoteRequests to signal whether the request is a PreVote or not. The candidate does not increase its epoch prior to sending the request out. The VoteResponse schema does not need any additional fields (still needs a version bump to match version bump for VoteRequest).

{
  "apiKey": 52,
  "type": "request",
  "listeners": ["controller"],
  "name": "VoteRequest",
  "validVersions": "0-1",
  "flexibleVersions": "0+",
  "fields": [
    { "name": "ClusterId", "type": "string", "versions": "0+",
      "nullableVersions": "0+", "default": "null"},
    { "name": "Topics", "type": "[]TopicData",
      "versions": "0+", "fields": [
      { "name": "TopicName", "type": "string", "versions": "0+", "entityType": "topicName",
        "about": "The topic name." },
      { "name": "Partitions", "type": "[]PartitionData",
        "versions": "0+", "fields": [
        { "name": "PartitionIndex", "type": "int32", "versions": "0+",
          "about": "The partition index." },
        { "name": "CandidateEpoch", "type": "int32", "versions": "0+",
          "about": "The bumped epoch of the candidate sending the request"},
        { "name": "CandidateId", "type": "int32", "versions": "0+", "entityType": "brokerId",
          "about": "The ID of the voter sending the request"},
        { "name": "LastOffsetEpoch", "type": "int32", "versions": "0+",
          "about": "The epoch of the last record written to the metadata log"},
        { "name": "LastOffset", "type": "int64", "versions": "0+",
          "about": "The offset of the last record written to the metadata log"},
        { "name": "PreVote", "type": "boolean", "versions": "1+",
          "about": "Whether the request is a PreVote request (no epoch increase) or not."}
      ]
 ...
}

...

• true if they haven't heard from a leader in fetch.timeout.ms . and all conditions that normally need to be met for VoteRequests are satisfied
• false if they have heard from a leader in fetch.timeout.ms (could help cover 'Servers in old configuration' scenario) . or conditions that normally need to be met for VoteRequests are not satisfied

(Not in scope) To address the disk loss and 'Servers in new configuration' scenario, one option would be to have servers respond false to vote requests from servers that have a new disk and haven't caught up on replication too.

How does this prevent unnecessary elections when it comes to network partitions?

...

Could this prevent necessary elections?

Yes, imagine a scenario where a leader is unable to receive fetch responses from a majority of nodes. If it were to remain leader, any nodes that are able to communicate with the leader would reject votes from a potential new leader that actually may be able to communicate with a majority of the cluster. 

How

• It doesn’t - Check Quorum ensures necessary elections can take place. Without it pre-vote can cause quorum unavailability.

"Check see “Check Quorum” for why we would need an additional safeguard

...