SERVER-44050 describes an issue in which the server incorrectly permits an array along a hash-indexed path. This leads to an index with incorrect index keys, which in turn can result in queries missing results. This issue has been fixed in our stable release branches. However, users may have existing clusters which still contain corrupt indexes that need to be recovered.

Ideally, users would be able to recover from SERVER-44050 by either deleting any illegal documents, or by updating these documents so that they do not contain an array along the hash-indexed path. However, any attempt to update or delete these documents will be rejected by a server that contains the fix for SERVER-44050. Not only does this make it more difficult to recover from SERVER-44050, but it is a problem in its own right that a collection can contain documents which cannot be updated or deleted.

As an example, suppose the following was executed on a server version that does not contain the fix for SERVER-44050:

> db.c.drop()
true
> db.c.createIndex({"a.b": "hashed"})
{
    "createdCollectionAutomatically" : true,
    "numIndexesBefore" : 1,
    "numIndexesAfter" : 2,
    "ok" : 1
}
> db.c.insert({a: [{b: 1}]})
WriteResult({ "nInserted" : 1 })

The user then updates the server to a version that contains the fix for SERVER-44050, and wishes to recover their corrupt node. In order to do so, they try to correct the document with an update/delete, but all such attempts fail and the index remains corrupted:

> db.c.find()
{ "_id" : ObjectId("5dc9f3c493197d531866f3f7"), "a" : [ { "b" : 1 } ] }
> db.c.remove({_id: ObjectId("5dc9f3c493197d531866f3f7")})
WriteResult({
	"nRemoved" : 0,
	"writeError" : {
		"code" : 16766,
		"errmsg" : "Error: hashed indexes do not currently support array values. Found array at path: a"
	}
})

Due to this limitation, users can only recover by first dropping the index, then cleaning up any documents with arrays on the hash-indexed path, and finally rebuilding the hashed index. These recovery steps could be operationally cumbersome, especially if the index is necessary to support hashed sharding.