PlanStages which do writes, such as UpdateStage, have special handling when
- documents are unowned and writes to them must be skipped,
- the update was broadcasted to multiple shards and must not be retried by mongos, and
- the update was targeted to a single shard and must not be retried by mongos.
All three of these cases exist in DeleteStage and TimeseriesModifyStage. The first two cases exist in BatchedDeleteStage. The third case had been initially forgotten from TimeseriesModifyStage and was only added later (SERVER-79408). The risk of a similar mistake like this being made again in the future is too high and the risk of violating the sharding metadata contracts are too severe. We should devote real engineering time to refactor how writes are executed within the query machinery to unify the implementations and to more confidently test the behavior.
- is duplicated by
-
SERVER-91921 Deduplicate StaleConfig handling from multi-write exec stages into handlePlanStageYield
-
- Closed
-
- is related to
-
SERVER-61127 Multi-writes may exhaust the number of retry attempts in the presence of ongoing chunk migrations
-
- Closed
-
-
-
- Closed
-
-
SERVER-78470 Prevent multi-false UpdateStage/DeleteStage from provoking yield after having already written
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-