[SERVER-48106] Remove all callers of FCV isVersionInitialized() Created: 11/May/20 Updated: 06/Dec/22 Resolved: 23/Jul/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
The FCV not being initialized during startup and initial sync has caused numerous bugs. See For example, we do not initialize the FCV during startup until well near the end, and before indexes are rebuilt. During initial sync, we clone admin.system.users and admin.system.roles before admin.system.version. The end result of this ticket should be to remove all callers of isVersionInitialized(). |
| Comments |
| Comment by Connie Chen [ 23/Jul/20 ] |
|
There is no easy way to invariant this, potentially a process change to happen during releases to check the callers. |
| Comment by Louis Williams [ 21/Jul/20 ] |
|
Additionally, |
| Comment by Louis Williams [ 21/Jul/20 ] |
|
I had a conversation with lingzhi.deng about this. The approach that Replication is taking with I think we should just reschedule this to evaluate callers of isVersionInitialized before the next release. That is: ensure callers of isVersionInitialized are not defaulting to a downgraded version behavior would cause unexpected behavior when the FCV changes to the upgraded version. |