When running a find query with the 'min' or 'max' parameters, the planner has logic to provide a default 'min' or 'max' value if none was provided. For example,

coll.find().hint({a: 1}).min({a: "foo"}) // 'max' will be defaulted to MaxKey.
coll.find().hint({b: -1}).min({b: "foo"}) // 'max' will defaulted to MinKey.

The relevant logic is here where we create a 'minObj' if none was provided. This object always has one key, regardless of how many components the index scan has. For example:

coll.find().hint({a: 1, b: 1}).min({a: "foo", b: "bar"}) // max key will only have one field.

Unfortunately, since the 'minObj' may not have the same number of fields as the index has components, converting this object to KeyString may give us an invalid result. That is, it may produce a KeyString which cannot be round-tripped back to BSON.

Fortunately, this problem is not (yet) observable since no attempt is made to roundtrip these invalid KeyStrings, and the KeyStrings appear to sort correctly. However, if any effort were made to convert these KeyStrings back to BSON (for logging purposes, for assertions, or for any other reason), the server would crash. This problem is a "bomb" waiting to cause issues, and the author spent nearly a full day stuck on this issue while working on other tasks.

We should change the query planner to create the correct number of elements in 'minObj' and 'maxObj'.