[SERVER-62483] Disabled feature flags lack of FCV gating causes crashes in all feature flags multi-version tests Created: 10/Jan/22 Updated: 27/Oct/23 Resolved: 13/Jan/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Gregory Wlodarek | Assignee: | Jason Chan |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Sprint: | Replication 2022-01-24 | ||||
| Participants: | |||||
| Linked BF Score: | 43 | ||||
| Description |
|
Feature flags that are disabled by default cannot have a version field to FCV gate the feature.
This is problematic for the all feature flags multi-version variants as some of these feature flags don't exist in earlier binaries, but it is possible to enable them regardless due to the lack of FCV gating. Running in a configuration where only a subset of mongod's have a feature flag enabled will result in different behaviour across the cluster. |
| Comments |
| Comment by Jason Chan [ 13/Jan/22 ] |
|
Followed up on this with gregory.wlodarek. We think this BF happened due to a misuse of the feature flag API. When a feature flag is set to default:false, the FCV it is already assigned a version value equal to the latest version. If a feature is meant to be FCV-gated, it should use the isEnabled() call to gate behavior. However, we think the feature in question is currently using isEnabledAndIgnoreFCV() which causes the feature to be enabled even while on an old FCV. Features should only be using isEnabledAndIgnoreFCV() in cases where their feature does not have any FCV gating requirements, or in very special cases where it has to be invoked in places of the code where FCV is not yet initialized/stable. In conclusion, we decided this ticket can be closed out as there was a misunderstanding of how the expected feature flag API is to be used. |
| Comment by Gregory Wlodarek [ 10/Jan/22 ] |
|
An approach that dan.larkin-york mentioned is to introduce a new field to the feature flag IDL named minFCV, which could be used to determine the earliest compatible binary for a given feature flag. CC robert.guo |