[SERVER-35136] Remove featureCompatibilityVersion document restoration based on UUIDs during --repair Created: 21/May/18 Updated: 09/Jul/18 Resolved: 09/Jul/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage, Upgrade/Downgrade |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Maria van Keulen | Assignee: | Louis Williams |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | nyc | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Sprint: | Storage NYC 2018-07-16 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
As of |
| Comments |
| Comment by Louis Williams [ 09/Jul/18 ] |
|
Closing because we do not want to prevent repair from completing for any reason, and because this is a very unlikely behavior in 4.2 that we are choosing not to support. |
| Comment by Louis Williams [ 06/Jul/18 ] |
|
The work here should be to unconditionally restore the FCV document to the value of the previous version. This is similar to the current behavior, but we will remove the code that uses UUID information to decide which version of the document to restore. For the future, we will no longer use any feature-specific side effects to deduce a data directory's FCV version. Unless the admin.system.version collection were corrupted, the only way the document could be missing is if the user were running on a 3.2 data directory, and we will explicitly not support that. In the unlikely event that the document is corrupted, we do not believe a user will have any reason to use a different binary version to run repair than the one they already have. If they do, undefined behavior should expected. |