-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Fully Compatible
-
Repl 2023-09-04, Repl 2023-09-18
Our current logic for processing responses from the MultistatementTransactionsRequestSender will just directly return to the user any local errors encountered while trying to send sub-batches to shards.
However, this is not always desirable because:
- If it's an unordered write, we should still try to complete the rest of the writes following those that failed in this sub-batch
- If it's an ordered write, we want to report results for any writes that succeeded before the sub-batch errored
We should update this logic to do something similar to batched writes, which is:
- if the error is a transient transaction error, return it directly to the user as a top-level error so the client may retry the entire transaction
- if the error is because the mongos is shutting down, return it directly to the user as a top-level error so the client may retry the command against another mongos
- otherwise, record the error as a per-statement error within the bulkWrite cursor (i.e. record it for the first write in the sub-batch if doing ordered writes, or all writes in the sub-batch for unordered)
- if we are in a transaction, abort execution (even if we are doing an unordered write) since we abort transactions on any errors
- is depended on by
-
SERVER-79506 Get all bulkWrite js core tests running in sharding passthrough suites
- Closed
-
SERVER-81006 Handle local errors executing retryable timeseries updates in bulkWrite
- Closed
- is related to
-
SERVER-89719 Coverity analysis defect 140504: Using invalid iterator
- Closed