When commands are registered, they can be configured to require a feature flag. For example:

MONGO_REGISTER_COMMAND(StartBlenderCmd)
    .requiresFeatureFlag(&feature_flags::gFeatureFlagBlender)
    .forShard();

 requiresFeatureFlag is documented as:

A command object will be created only if the featureFlag is enabled, regardless of the current FCV.

Thus the documented behavior is that commands are registered if the feature flag is declared in the IDL with default: true, regardless of the IDL version field and the server FCV. Before SERVER-82270, this matched the implementation.

However, SERVER-82270 changed the code to instead check the feature flag using featureFlag->isEnabledUseLatestFCVWhenUninitialized(fcvSnapshot), where fcvSnapshot is the FCV at startup time. This means that command registration now depends on the FCV - and since it runs only once at startup, commands depending on FCV-gated feature flags remain not registered long after their feature flag has been enabled.

On v8.0, the VoteAbortIndexBuild command, which requires an FCV-7.1-gated flag, is affected by this issue. Consider this typical upgrade sequence:

• A cluster is running on binary 7.0 + FCV 7.0
• The binaries are upgraded to 8.0
• At startup, command registration runs, but since the FCV is 7.0, the VoteAbortIndexBuild command is not registered
• The FCV is upgraded to 8.0 - note registered commands stay the same
• Long after the upgrade is fully completed, an operation running on the fully upgraded cluster runs VoteAbortIndexBuild and unexpectedly receives a CommandNotFound error

A reproducer is attached.