[SERVER-31143] Ensure 3.4 binaries crash if they contain a UUID Created: 18/Sep/17  Updated: 29/Jan/18  Resolved: 29/Sep/17

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

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Louis Williams
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage 2017-10-23
Participants:

 Description   

In a replica set, after setFeatureCompatibilityVersion: 3.4 returns successfully, it is still possible for a minority of nodes to contain UUIDs. If a user then shuts down those nodes and downgrades their binaries to 3.4, the UUIDs will stick around and get stale while the data changes.



 Comments   
Comment by Louis Williams [ 29/Sep/17 ]

Duplicates behavior of SERVER-31209

Comment by Louis Williams [ 29/Sep/17 ]

If a minority node has UUIDs, then it still has a targetVersion field set in the featureCompatibilityVersion document. This field is only removed once the upgrade is complete. As schwerin correctly pointed out, a 3.4 binary will not start in this case.

Comment by Andy Schwerin [ 28/Sep/17 ]

Yes, I think that 3.4 won't start up when the targetVersion field is present, so I think this is a duplicate of the targetVersion work.

Comment by Eric Milkie [ 20/Sep/17 ]

Will the new design for the values of admin.system.version help with this issue?

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