-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
v8.0
-
CAR Team 2024-06-24, CAR Team 2024-07-08, CAR Team 2024-07-22
-
200
In testing, we have observed cases where a deleteMany running while a moveCollection commits returns a StaleConfig error which is retried by mongos, leading to an unexpected value for n in the response (because some of the deletes happened on the donor shard, then the rest of the deletes happened on the recipient shard after the retry, and n only captures the deletes that occurred on the recipient).
We are concerned that similar behavior exists for updateMany where a StaleConfig after a moveCollection to lead it to retry and update the same document twice (once on the donor originally, and once again on the recipient after the retry). However, at the time of writing, this has not been observed to happen in testing.
This ticket is to do the following:
1. Verify whether or not the scenario described above can occur for updateMany.
2. If it can, make updateMany fail with some error that mongos will not retry instead of StaleConfig.
- causes
-
-
- Closed
-
- has to be done after
-
SERVER-91568 Switch ShardRoleTest to use ShardServerTestFixture
-
- Closed
-
-
-
- Closed
-
- is depended on by
-
-
- Closed
-
- is related to
-
-
- Closed
-
- related to
-
-
- Closed
-
-
SERVER-92126 Consolidate functions used for iterating PlanExecutor in bulkWrite update statements and update command
-
- Closed
-