-
Type: Task
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Optimization
-
QO 2023-10-02, QO 2023-10-16
This ticket has been split from an audit of all Query 7.0 feature flags. This ticket is a request to audit gFeatureFlagChangeStreamsFurtherEnrichedEvents.
Intial sync can temporarily reset the fcv value to uninitialized and sets the new value afterwards. This can cause call sites trying to inspect the fcv value to hit this invariant. We need to audit feature flag usage and determine which should do one of the following:
- It can never be called when initial sync is running. So do nothing. Note that this can be tricky to prove as we once thought the catalog cache loader can never be run while initial sync is happening but it can.
- It is safe to ignore fcv version so use isEnabledAndIgnoreFCVUnsafe instead (i.e. if the FCV is unintialized during initial sync, the feature flag will be on if it's enabled)
- It is safe to turn off the feature anytime (even if feature flag is actually on) so use isEnabledUseDefaultFCVWhenUninitialized instead (i.e. if the FCV is unintialized during initial sync, the feature flag will be off, even if it's actually enabled on a later version)
- Special logic is needed if fcv is not initialized (for example, waiting for the FCV to become initialized before checking isEnabled)
- is related to
-
SERVER-79317 Provide more documentation and helper functions for case where feature flag checks could be run when fCV is uninitialized during initial sync
- Closed