[DRIVERS-2170] Errors on retryable ops should indicate originating server when possible Created: 08/Oct/19 Updated: 11/Jan/24 |
|
| Status: | Implementing |
| Project: | Drivers |
| Component/s: | Retryability |
| Fix Version/s: | None |
| Type: | Spec Change | Priority: | Major - P3 |
| Reporter: | Jeremy Mikola | Assignee: | Jamis Buck |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Driver Changes: | Needed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quarter: | FY24Q4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Downstream Changes Summary: | Summary of necessary driver changes This only affects drivers that include server information (like the server name or address) in exceptions and error messages. Any driver that includes server information in an exception or error message must ensure that the exception or message refers to the server that originated the error. For example, during a retry of a failed read or write, the original server must not simply be carried over to a subsequent error. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Engineering Lead: | |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Start date: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Driver Compliance: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
While discussing some of the error reporting improvements that oleg.pudeyev has added to the Ruby driver, I learned that Ruby goes out of its way to report the specific server that produced an error ultimately reported when a retryable operation totally fails. This overcomes possible ambiguity where an operation can report an error message corresponding to the first or second attempt. Executing Retryable Write Commands states:
While Command Monitoring can also be used to infer the error's originating server, we can't rely on that being enabled in production systems where applications might only be logging an exception. The Retryable Reads spec does not appear to have any section discussing error reporting (possible oversight), but it should also be able to implement this. If a driver already attaches a server description (or equivalent) to its exceptions for server-side errors, I think they could implement this ticket just by ensuring that the attached server is always the originating server of the error being reported. For example, a driver that always attaches the first attempt's server to such an exception should be changed to conditionally attach the first or second accordingly. |
| Comments |
| Comment by Githook User [ 09/Jan/24 ] |
|
Author: {'name': 'Jamis Buck', 'email': 'jamisbuck@gmail.com', 'username': 'jamis'}Message: DRIVERS-2170 Server info on retryable errors must reflect the originating server (#1480)
|
| Comment by Jamis Buck [ 11/Dec/23 ] |
| Comment by Oleg Pudeyev (Inactive) [ 08/Oct/19 ] |
|
FYI, in Ruby this diagnostic is applied to all failing operations, not just those eligible to be retried. |