Feature flag checks can race with the setFCV command, causing undesirable behavior during an upgrade or downgrade. For each feature flag with shouldBeFCVGated: true enabled in 8.0, please double check that:

• Each thread only checks the feature flag once
  • Risk: Otherwise the first feature flag check could return one result while a subsequent check returns a different result. This could cause the feature to partially execute in an unexpected way
• If the feature affects what could be written to disk, that we are holding the global lock in a mode conflicting with S when doing feature flag checks
  • Risk: Otherwise there is a race condition possible where the feature flag check returns one result and then the setFCV operation fully completes (either an upgrade or a downgrade). This would mean that the original operation could execute in an FCV that should not be allowed
• If the feature affects what could be written to disk, we do not execute feature flag checks on secondaries performing oplog application. The oplog entry itself should tell the secondary how to execute the operation.
  • Risk: If a secondary can make its own decision on what the FCV dictates the feature should be, it can race with setFCV and make a different decision than the primary, causing its data to diverge from the primary’s data.

The FCV and Feature Flag README details these safety rules as well.

Please audit the checks for the following feature flags:

• featureFlagAllowAdditionalParticipants
• featureFlagTransitionToCatalogShard
• featureFlagUpdateOneWithoutShardKey
• featureFlagPauseMigrationsDuringMultiUpdatesAvailable
• featureFlagMoveCollection
• featureFlagUnshardCollection
• featureFlagReshardingForTimeseries
• featureFlagUpdateOneWithIdWithoutShardKey