[SERVER-80902] Audit gFeatureFlagTelemetry Created: 08/Sep/23  Updated: 05/Dec/23  Resolved: 30/Nov/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.3.0-rc0

Type: Task Priority: Major - P3
Reporter: Kyle Suarez Assignee: Charlie Swanson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-85096 TRACKING: M3 Correctness Tickets Closed
Duplicate
is duplicated by SERVER-80906 Audit gFeatureFlagTelemetry Closed
Related
related to SERVER-79317 Provide more documentation and helper... Closed
is related to SERVER-79330 Audit featureFlag usage in v7.0 branc... Backlog
Assigned Teams:
Query Integration
Backwards Compatibility: Fully Compatible
Backport Requested:
v7.0
Participants:

 Description   

This ticket has been split from an audit of all Query 7.0 feature flags. This ticket is a request to audit gFeatureFlagTelemetry.

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 if the feature flag check can be run during initial sync:

If it can never be called when initial sync is running, 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.

If it might get run during initial sync, this could be the case if the feature is run during initial sync itself, if the feature is in a background thread that runs during initial sync, or if the feature is run in a command that is allowed during initial sync, such as hello, serverStatus, etc. In this case, use one of these options:

  • Use isEnabledUseLastLTSFCVWhenUninitialized. It checks against the last LTS FCV version if the FCV version is unset, but note that this could result in the feature not being turned on even though the FCV will be set to latest once initial sync is complete.
  • Use isEnabledUseLatestFCVWhenUninitialized. This instead checks against the latest FCV version if the FCV version is unset, but note that this could result in the feature being turned on even though the FCV has not been upgraded yet and will be set to lastLTS once initial sync is complete.
  • Write your own special logic to avoid the invariant (for example, waiting for the FCV to become initialized before checking isEnabled, or uasserting instead of invariant-ing)

See this section of the README



 Comments   
Comment by Githook User [ 30/Nov/23 ]

Author:

{'name': 'Charlie Swanson', 'email': 'charlie.swanson@mongodb.com', 'username': 'cswanson310'}

Message: SERVER-80902 Avoid checking feature flag at query stats startup
Branch: master
https://github.com/mongodb/mongo/commit/717b5962d8624ddf066e6336e140d90be5e049a8

Comment by Charlie Swanson [ 06/Nov/23 ]

PR: https://github.com/10gen/mongo/pull/16670

Comment by Charlie Swanson [ 30/Oct/23 ]

re-opening to track analysis on the 7.0 branch, since I mistakenly just looked at master when resolving. 

Comment by Charlie Swanson [ 05/Oct/23 ]

I don't think there's any change needed here. Based on the boilerplate comment here I was going to switch our code to use 'isEnabledUseDefaultFCVWhenUninitialized', but it looks like that is now the default behavior of 'isEnabled' as of SERVER-70202. Closing this out.

Comment by Brenda Rodriguez [ 14/Sep/23 ]

kyle.suarez@mongodb.com How is this ticket different from upgrade/downgrade feature flag (SERVER-80031)?

Generated at Thu Feb 08 06:44:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.