-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
-
None
-
None
-
None
-
None
-
None
-
None
-
None
When shards execute non-atomic batched writes, they are supposed to report each write's outcome individually in the response payload rather than through the top-level command status. This allows a router to determine which writes definitely succeeded, failed, or were not attempted, and then retry writes when appropriate and report the partial outcome to the user when retrying is not possible. Returning a top-level command error after partially executing the batch would lose these results.
Historically, unexpected exceptions have escaped from shard-side write commands as top-level errors after some writes had already completed. (see SERVER-131302, SERVER-81508, SERVER-77116)
Proposal: Add a tassert at the shard-side batched write response boundary that fires if the command would return a top-level error after at least one write completed successfully. In production, this should result in a non-retryable BrokenWriteProtocol-type error indicating that the server cannot accurately report the outcome of the write batch.
- is related to
-
SERVER-77116 Checking shard version during restore can cause StaleConfig exception propagated for writes incorrectly
-
- Closed
-
-
SERVER-108071 Handle top level StaleConfig errors in write commands
-
- Blocked
-