[DRIVERS-2247] Add tests for non-retryable handshake errors Created: 25/Mar/22  Updated: 25/Apr/22

Status: Backlog
Project: Drivers
Component/s: Retryability
Fix Version/s: None

Type: Improvement Priority: Unknown
Reporter: Daria Pardue Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: leads-triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Issue split
split to CDRIVER-4322 Add tests for non-retryable handshake... Blocked
split to CSHARP-4123 Add tests for non-retryable handshake... Blocked
split to CXX-2479 Add tests for non-retryable handshake... Blocked
split to GODRIVER-2363 Add tests for non-retryable handshake... Blocked
split to JAVA-4557 Add tests for non-retryable handshake... Blocked
split to NODE-4150 Add tests for non-retryable handshake... Blocked
split to PHPLIB-830 Add tests for non-retryable handshake... Blocked
split to PYTHON-3195 Add tests for non-retryable handshake... Blocked
split to RUBY-2941 Add tests for non-retryable handshake... Blocked
split to RUST-1249 Add tests for non-retryable handshake... Blocked
split to MOTOR-921 Add tests for non-retryable handshake... Closed
Related
related to DRIVERS-1842 Drivers should retry authentication e... Backlog
related to DRIVERS-746 Drivers should retry operations if co... Implementing
is related to NODE-4206 Add coverage for non retryable error ... Blocked
Driver Changes: Needed
Driver Compliance:
Key Status/Resolution FixVersion
CDRIVER-4322 Blocked
CXX-2479 Blocked
CSHARP-4123 Blocked
GODRIVER-2363 Blocked
JAVA-4557 Blocked
NODE-4150 Blocked
MOTOR-921 Duplicate
PYTHON-3195 Blocked
PHPLIB-830 Blocked
RUBY-2941 Blocked
RUST-1249 Blocked
SWIFT-1534 Won't Do

 Description   

Summary

DRIVERS-746 introduced spec language around retrying handshake errors, and there is still some ongoing discussion regarding whether that specification is complete. Regardless of the specific criteria for retryable errors, it is clear that not all handshake errors should be retryable (depending on the error type as well as the retryable reads/writes client settings); however, there are currently no spec tests for asserting that a driver should not retry particular handshake errors given some set of conditions. This could result in driver implementations that incorrectly retry on every handshake error regardless of error type, code, or client retryability settings.

Is this ticket only for tests?

Yes



 Comments   
Comment by Shane Harvey [ 13/Apr/22 ]

This does not seem urgent but at the same time a new test for a non-retryable error should be fairly straightforward to add. If someone has the time it seems fine to pick up.

Comment by Jeremy Mikola [ 02/Apr/22 ]

shane.harvey suggested this might not actually be urgent, as the worst case is having drivers retry handshake errors they otherwise should not (which may be beneficial to users). He also referenced DRIVERS-1842, which pertains to retrying after AuthenticationFailed (context is an inaccessible LDAP server), so I'll mark that as related.

Comment by Jeremy Mikola [ 01/Apr/22 ]

daria.pardue: Apologies. I didn't realize we could schedule w/o assigning. Just did so and will alert the leads to talk this over at next week's meeting.

Comment by Daria Pardue [ 01/Apr/22 ]

jmikola I would recommend scheduling it or at least pushing it to leads triage; in the Node driver, our first pass at the implementation of DRIVERS-746 ended up retrying everything - we caught it in code review, but it would be good to have actual spec tests that catch it.

Comment by Jeremy Mikola [ 01/Apr/22 ]

Moving this to the backlog as a matter of course, but it seems timely given that DRIVERS-746 is currently being implemented. If anyone wants to pick up this spec work or propose that the leads schedule it, feel free to do so.

Generated at Thu Feb 08 08:25:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.