Currently, a request's shard version is parsed and then the server immediately asserts that it can accept sharded commands (i.e. its sharding state is initialized). Instead, this should be checked after waiting for readConcern, so the server will have waited if afterClusterTime was given. This would allow a secondary that hasn't finished setting up its sharding state to accept a read with a valid shard version and afterClusterTime >= the optime of the insert of the shard identity document on the primary instead of throwing an error.
- related to
-
SERVER-34597 shardedcluster.py does not wait correctly on shards initialization
- Closed