[SERVER-58787] Incorrect use of candidateIndex from a previous config during vote processing. Created: 23/Jul/21  Updated: 06/Dec/22  Resolved: 26/Jul/21

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Wenbin Zhu Assignee: Backlog - Replication Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-47007 candidateIndex field of LastVote docu... Backlog
Related
is related to SERVER-57262 Allow nodes to vote for candidates wi... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

After we granted vote for a node in config C0, and recorded the `candidateIndex` in `lastVote`, later we could install a new config C1 from another node due to heartbeat, and next time when we are voting, our `_rsConfig` is already a new one, but the `candidateIndex` was based on an old config, so calling `_rsConfig.getMemberAt(_lastVote.getCandidateIndex())` is not correct. This would result in incorrect logs and metrics. Ideally we should record in `_lastVote` the direct information of the candidate node (like memberId and host/port) instead of an index which can vary across configs. This is regardless of using the strict config term/version comparison rule or the relaxed one.


Generated at Thu Feb 08 05:45:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.