Consider the startup sequence of a mongod which is both a replica set member and a shard server (i.e. a member in a replica set, where the replica set is a shard in a sharded cluster). When a node starts up with the --shardsvr flag, it needs to initialize some aspects of the sharding system. In particular, it needs to read a document out of the admin.system.version collection with _id:"shardIdentity" in order to establish things like its shard id and the config server connection string.

This node also needs to perform some initialization tasks for the replication subsystem, in particular replication recovery. This involves replaying oplog in order to ensure that the collection and indices are consistent with all committed writes in the oplog before the node services queries.

The problem observed in this ticket is that sharding initialization takes place prior to replication recovery. Therefore, the sharding system may attempt to perform reads, at least reads against admin.system.version, before replication recovery has occurred. Sharding initialization could therefore fail to see committed data. For example, it could fail to see the shard identity document, even though the write of the shard identity document was committed.