[DRIVERS-2327] Propagate Original Error for Write Errors Labeled NoWritesPerformed Created: 12/May/22 Updated: 27/Jan/23 |
|
| Status: | Implementing |
| Project: | Drivers |
| Component/s: | Retryability |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Preston Vasquez |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Driver Changes: | Needed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Server Compat: | 6.1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quarter: | FY23Q3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Upstream Changes Summary: | Commands which failed with the RetryableWriteError label can now also return a new NoWritesPerformed error label if no writes were performed during the operation of that command. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Downstream Changes Summary: | Drivers need to implement a new retryable writes prose test (see mongodb/specifications@e4a5564), and implement operation error handling such that if a retry event fails with an error labeled NoWritesPerformed the original error is propagated. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Driver Compliance: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
SummaryWhat 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 MotivationWho is the affected end user?Who are the stakeholders? How does this affect the end user?Are they blocked? Are they annoyed? Are they confused? How likely is it that this problem or use case will occur?Main path? Edge case? 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? 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? |
| Comments |
| Comment by Valentin Kavalenka [ 12/Oct/22 ] |
|
For future readers: this issue is caused by SERVER-66116. |
| Comment by Rachelle Palmer [ 28/Sep/22 ] |
|
Nope, that's good enough for me |
| Comment by Neil Shweky (Inactive) [ 28/Sep/22 ] |
|
rachelle.palmer@mongodb.com I have merged a PR requiring 6.0+, does this need to be changed? |
| Comment by Githook User [ 13/Sep/22 ] |
|
Author: {'name': 'Neil Shweky', 'email': 'neilshweky@gmail.com', 'username': 'Neilshweky'}Message: DRIVERS-2327: limit prose test to server versions 6.0+ (#1304)
|
| Comment by Githook User [ 01/Sep/22 ] |
|
Author: {'name': 'Preston Vasquez', 'email': '24281431+prestonvasquez@users.noreply.github.com', 'username': 'prestonvasquez'}Message: DRIVERS-2327 NoWritesPerformed Retryable Writes Error Handling (#1297) |