-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Component/s: Retryability
-
None
Summary
What is the problem or use case, what are we trying to achieve?
We have definite (write definitely aborted) and indefinite (write may have committed) errors we return to the client and we do not make it clear which are definite and which are indefinite.
We want to change the driver spec to return indefinite errors any time it could be indefinite. For example, WriteConcernErrors and SocketExceptions are both indefinite. The Server is in the best position to say (probably via an error label) which errors returned by the server are definite. On bulk writes, NotWritablePrimary is the only definite retryable error. NoSuchTransaction is also definite and handled specially by the driver, though it is not labeled “retriable”. Writes with multi:true are not retryable and thus there is no question about the error a driver should return.
Error labels were introduced in 4.3.1 by SERVER-43941. For brevity, the prose tests must only run on versions >= 6.0.
Motivation
Who is the affected end user?
Who are the stakeholders?
Anyone using retryable writes or transaction retryability.
How does this affect the end user?
Are they blocked? Are they annoyed? Are they confused?
If the driver stops retrying for them, they could take an incorrect action and accidentally double commit a write.
How likely is it that this problem or use case will occur?
Main path? Edge case?
This is on the main error path, but with CSOT will become less likely.
If the problem does occur, what are the consequences and how severe are they?
Minor annoyance at a log message? Performance concern? Outage/unavailability? Failover can't complete?
Users may take incorrect action based on unclear information we provide.
Is this issue urgent?
Does this ticket have a required timeline? What is it?
Is this ticket required by a downstream team?
Needed by e.g. Atlas, Shell, Compass?
Is this ticket only for tests?
Does this ticket have any functional impact, or is it just test improvements?
This has a functional impact.
- depends on
-
SERVER-66479 Create an error label indicating if a retryable error is "definite".
- Closed
- is depended on by
-
SERVER-66116 Aborted Read with MongoNotPrimaryException
- Blocked
- is related to
-
SERVER-69295 Mongos NoWritesPerformed errors MUST return original error
- Backlog
-
DRIVERS-2468 Add a test that drivers emit a CommandSucceededEvent when ok=1 and a writeConcernError is returned
- Implementing
- related to
-
DRIVERS-2501 Break NoWritesPerformed-Only Error Sequence
- Implementing
-
SERVER-69129 Successive Errors in FailCommand
- Backlog
-
PYTHON-1573 db.collection.bulkWrite() does not return insertedIds {}
- Backlog
- split to
-
CSHARP-4288 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Backlog
-
CXX-2563 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Backlog
-
CDRIVER-4449 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Closed
-
GODRIVER-2516 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Closed
-
MOTOR-1013 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Closed
-
PHPLIB-935 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Closed
-
PYTHON-3388 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Closed
-
RUBY-3079 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Closed
-
RUST-1433 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Closed
-
JAVA-4701 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Closed
-
NODE-4503 Propagate Original Error for Write Errors Labeled NoWritesPerformed
- Closed