The problem:

When we check whether an index spec is valid, we inspect the parsed partialFilterExpression and check whether each operator is allowed under the current FCV. For example $or is allowed in a partial filter expression in 6.0 but not 5.x.

However, when you downgrade FCV from 6.0 to 5.x, we are not checking whether existing partial indexes are allowed under 5.x. You end up with new features in the datafiles, but an old FCV. Then during startup, we do check FCV and reject the index, so the server fails to start.

Another reason we shouldn't check FCV during startup is that determining FCV in the first place requires loading the catalog for the admin database. So if you create any partial index on the admin database (regardless of 6.0 features), then we check FCV before FCV is initialized, which fails (regardless of the value of FCV: 5.x or 6.0).

The solution:

1. We should not check FCV during startup. When we validate a partialFilterExpression that we loaded from the datafiles, we should assume any new features are allowed. We should backport this change to 6.0.
   • For any existing datafiles, this will allow you to start the latest 6.0.x binary and either upgrade FCV or drop some indexes.
2. We should check for 6.0-only features in partial indexes when the user attempts to downgrade FCV, and fail with CannotDowngrade if we find any.
   • For any existing datafiles, 5.x binary will still safely reject 6.0-only partial indexes during startup.

Workarounds (requested here in HELP-42790):

For future HELP tickets that run into this issue and are on a version earlier than 6.0.5, the only known workaround is to drop the partial indexes on the admin database. They can then be replaced with non-partial indexes and the FCV issue should be resolved.