Version 3.4 introduced stricter validation of index specifications.

However, the new code is only run when an index is recreated, meaning the following scenario is all too possible:

• In version 3.2, an index with key {cust_id:1, background:true} is created.
• The weaker syntax checking in that version does not catch the missing }, { and instead of a single field index on cust_id created in background, a compound index is created in the foreground with a non-existent second field called "background" appended to the key).
• upgrade in place to 3.4 of PSA replica set goes through without error
• more upgrades to 3.6 and 4.0 can also succeed.
• Then when hardware failure necessitates the resyncing of a node, it fails on the recreate of this index due to the non-compliant definition.
• likewise if the OM/CM headDB becomes stale and needs to be resynced, it will fail.

To enable DBA's to detect and fix index definitions that do not comply with the stricter rules in version 3.4 and later, it would be nice if the upgradeCheck utilities (or some other new utility) existed that would examine all indexes for a collection/database/cluster and report on those that cannot be upgraded.

It would be better to discover and repair them in planned outage windows than in the midst of an already unplanned outage.

Many of these boolean fields in version 3.2 index keys are called unique, sparse and background, meaning they were almost certainly intended to be index options and not part of the key, so the index is not created as intended either, and it is in the customer's interest to fix that too.