Index multikey metadata can either become inconsistent with collection data or more permissive than the data requires. There are three main ways this can happen:

1. Indexes built before 3.4 (SERVER-15086) lack path-specific multikey metadata. All fields in an index are considered multikey and require blocking sorts. See SERVER-33387.
2. Collection data has changed such that certain document paths are no longer multikey.
3. Bugs: SERVER-48471, SERVER-47694, SERVER-43074, etc.

Multikey metadata may only be made less restrictive. If a collection's data has changed such that an index no longer has multikey documents or the multikey paths include more fields than are multikey, then the multikey metadata may be inconsistent. This is correct and allowed by the implementation, but it can lead to undesirable performance problems. The only solution is to reindex.

Collection validation scans all documents and generates multikey information, and it has the ability to fix index multikey metadata without returning an error. Allow foreground validation to "fix up" the following permitted inconsistencies:

• An index is multikey but there are no multikey fields
• An index has multikeyPaths covering fields that are not multikey
• An index does not have multikeyPaths but there are multikey documents (for pre-3.4 indexes)