-
Type: Bug
-
Resolution: Gone away
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
None
-
ALL
-
Sharding 2020-09-21, Sharding 2020-10-05, Sharding 2020-10-19
-
13
After addShard, we call ShardRegistry::reload() on the router so that the following request on the same client will be able to target that shard without receiving a ShardNotFound error. However, with the streamable replica set monitor, calls to onPossibleSet can then overwrite the host data on the ShardRegistry concurrently, leading to a ShardNotFound error on a subsequent request. It doesn't seem like there was ever a guarantee of shard add/remove operations being causally consistent with CRUD ops in any meaningful way, but this breaks tests that used to rely on the shard being available after addShard.
- is related to
-
SERVER-35252 All config server metadata commands that read from ShardRegistry might read stale data
- Backlog
-
SERVER-46202 Implement ShardRegistry on top of ReadThroughCache to make it causally consistent
- Closed
- related to
-
SERVER-48996 Race between isMaster response connection hook and RSM topology change triggers ShardNotFound
- Closed