Sharding on a key that's a prefix of an existing index can leave assertions in the logs that look like:

 m30001| Wed Aug 22 22:00:27 [conn4] assertion 10367 no index found for specified keyPattern: {} min: { a: 0.0 } max: { a: MaxKey } ns:test.foo query:{ query: {}, $min: { a: 0.0 }, $max: { a: MaxKey } }

The source of these assertions is a query made at the end of the "splitChunk" command. The query errors because it assumes the existence of an index that's an exact match for the shard key. The query is only used to decide whether to append the "shouldMigrate" flag to the result of the command, which in turn is used as some sort of heuristic by Chunk::splitIfShould() to decide which chunk to move after the split. Leaving out the "shouldMigrate" flag does not appear to affect correctness. I suspect this heuristic is rarely triggered anyway. However because of this issue, using a prefix shard key may yield slightly different behavior than a shard key with an exact index match.

Test attached which shows the assertions.