[GODRIVER-3070] Investigate adding a RetryableError interface to mongo package Created: 12/Dec/23  Updated: 18/Dec/23

Status: Backlog
Project: Go Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Unknown
Reporter: Preston Vasquez Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GODRIVER-2191 Drivers should retry operations if co... Blocked
is related to GODRIVER-2579 Incorporate connection pool checkout ... Backlog

 Description   

Context

There are various errors in the Go Driver that have Retryable() methods. These include

  • WriteCommandError
  • WriteConcernError
  • poolClearedError
  • retryableError

Currently there exists an interface called RetryablePoolError in the driver package for which all of these errors implement. However, it doesn't quite fit the context of any of the errors except poolClearedError.

It would be convenient for users to be able to check if an error is retryable at the mongo-package level. For example:

rerr, ok := err.(mongo.RetryableError)
 
if ok && rerr.Retryable() {
   // do something knowing the error is retryable
}

mongo.Retryable would look something like this:

type RetryableError interface {
   Retryable() bool 
}

Definition of done

We should answer the following questions before implementing:

1. Is it driver-appropriate to provide a way for users to determine if an error is retryable? I.e. is this something we should give an opinion on?
2. Is providing an interface the best solution. Could we instead check the retryablity internally and wrap the error in an error-implementing struct?

Pitfalls

It could be dangerous to add opinions on retryable errors in the stable API.



 Comments   
Comment by KeAna Moutra [ 18/Dec/23 ]

Need additional use case info such as when are users able to determine retryability vs driver having retryability logic with non pool retryability.

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