[SERVER-47511] Prevent comparison of member indexes from different config versions Created: 13/Apr/20  Updated: 06/Dec/22

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

Type: Improvement Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: former-quick-wins
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-47125 Require ReplSetMetadata.isPrimary, re... Closed
Assigned Teams:
Replication
Participants:

 Description   

SERVER-46667 and other bugs are the result of comparing member indexes from different replica set configs, or using a member index from one config as an array index in a different config.

Devise a way to avoid repeating these sorts of bugs. Two ideas:

1. Minimize all use of member indexes from configs, ReplSetMetadata, OplogQueryMetadata, etc. Try to find alternative means of accomplishing the same goals.
2. Anywhere that member indexes are compared, include the config version and term. Perhaps create a MemberIndex class that has an index, version, and term. Two MemberIndexes cannot be compared unless their versions and terms agree. The name MemberIndex may be too similar to MemberId, so let's ponder the name.
3. Hide member indexes behind safe interfaces. E.g., instead of using OplogQueryMetadata.getSyncSourceIndex() directly, create safer methods like hasSyncSourceIndex() or isSameSyncSourceIndex(MemberIndex i).



 Comments   
Comment by A. Jesse Jiryu Davis [ 16/Apr/20 ]

In SERVER-47125, I plan to replace OplogQueryMetadata::getPrimaryIndex() with hasPrimaryIndex(). The only information we need is whether the primary index is -1. Changing the accessor method from int to bool prevents future bugs where we try to compare the primary index with a member index from a different config. We should do the same with OplogQueryMetadata::getSyncSourceIndex().

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