ISSUE SUMMARY
Updates over array elements with an explicit numerical path component (e.g. a.5.c), where the array element does not yet exist, can fail to generate null index keys for multikey indexes on other fields in the array element (e.g. for the index {"a.b": 1}). Updates using the $ positional operator are not affected. This index corruption will cause equality to null queries to miss results.

UPDATES CAUSING INDEX CORRUPTION
The following updates will fail to generate a null index key for the index {"a.b": 1}:

• Updates to a.<n>.c, where <n> is an integer greater than or equal to the length of the array a, and a is not empty. The update must create the array element a.<n> to cause index corruption, so it must be one of $set, $inc, $mul, $addToSet, $bit, $min, $max, $currentDate, or $push, $pushAll.

The following updates are not affected:

• Updates to a.<n>.c, where <n> is less than the length of the array a.
• Updates to a.<n>.c, when the array a is empty.
• Updates to a.$.c.
• Updates to a.<n>.
• $rename, $setOnInsert, $unset, $pop, $pull, and $pullAll.

QUERIES AFFECTED BY INDEX CORRUPTION
The following queries will miss results due to index corruption of {"a.b": 1}:

• {"a.b": null}

The following queries are not affected:

• {"a.b": {$exists: false}}
• {"a.b": {$exists: true}}
• {"a.b": {$ne: null}}

HOW DO I TELL WHETHER I'M AFFECTED?
If you have never issued updates with explicit numerical path components, you're not affected. In order to test whether you are affected, run the validate command with full:true.

HOW DO I RECOVER?
Rebuild any affected indexes.

HOW TO PREVENT THIS ISSUE?
Upgrade to a version where this issue is fixed. The issue is fixed in 3.6.1, 3.4.11, 3.2.19, 3.0.16.

AFFECTED VERSIONS
This affects 3.0.15 and earlier versions of 3.0; 3.2.18 and earlier versions of 3.2; 3.4.10 and earlier versions of 3.4; 3.6.0 and earlier versions of 3.6.

FIX VERSION
3.6.1, 3.4.11, 3.2.19, 3.0.16