The failIndexKeyTooLong server parameter was introduced as a way to permit indexes created in version 2.4 or earlier to be migrated to version 2.6, despite them having documents with field values longer than 1024 bytes and indexes on those fields.

The intention was that customers would clean up their data or change the index definitions so that the key field values for all documents were under the Index Key Limit of 1024 bytes, and return failIndexKeyTooLong to its default of true. This has not happened -there are still customers with failIndexKeyTooLong=false in version 3.4.

Indexes created or updated while failIndexKeyTooLong=false ignore any documents where the total key field length exceeds the Index Key Limit. If there are documents with long keys that would match a particular query, plans that use an IXSCAN against those indexes silently return fewer documents than plans that use other indexes or collection scans.

While failIndexKeyTooLong is a server wide parameter, any document insert or update into any collection could include an overlong key field, and the index(es) on that collection would potentially return incomplete results for queries that should have included the document with the long key.

If we change failIndexKeyTooLong to be an option passed to createIndex() and visible in getIndexes() output, then database users will know that queries using that index might not return all the qualifying documents, and can force use of a different plan if they desire.