Creating the compound index AFTER sharding the collection potentially allows the balancer to kick-in in the middle leading to a failure when trying to refine the shard key.

Lengthy explanation
During test setup the following actions are performed in a loop that goes from fsmcoll0_25 to fsmcoll0_0:

• Create the sharded collection
• Create the index to be used for refine

Aftwerards, refine happens as part of the refineCollectionShardKey state.

A test failure signaled that shard0 did not seem to have the index {a:1, b:1} for test15_fsmdb0.fsmcoll0_25 when trying to refine the shard key from {a:1} to {a:1, b:1}. Question is: why was the index created during the setup not found when trying to refine the shard key?

From the logs we can see that:

1. The primary shard for test15_fsmdb0 is shard1
2. The collection gets sharded
3. The balancer kicks in right when the doc is inserted in config.collections
4. A migration starts from shard1 to shard0
5. The refined index is created
6. The migration succeeds

The migration started on (4) resulted in the recipient cloning the indexes before (5). Hence the index was never created on shard0 because createIndex is not serialized with migrations and is only sent with a scatter gather by routing table to the shards owning chunks (so - at time 4.5 - only to shard1).