-
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
-
None
-
None
-
None
-
None
-
None
-
None
-
None
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
-
-
- Backlog
-
-
SERVER-46202 Implement ShardRegistry on top of ReadThroughCache to make it causally consistent
-
- Closed
-
- related to
-
-
- Closed
-