-
Type:
Spec Change
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Component/s: Retryability
-
None
One of the goals of Client Backpressure is to enable the server to report metrics on both rejected commands and successfully retried commands. The second requires clients to attach metadata to retried commands like "retry": 1.
We may also want to attach other metadata like the backoff & jitter durations (DRIVERS-3239), and client retry budget (DRIVERS-3240).
When the system overload retry loop decides to short circuit a retry or hits a non-retryable error, it should be easy to diagnose why that decision was made. Ideally, we could answer the following questions:
- Was the last error retryable or non-retryable? And why? EG did the mongos return an overload error without the retryable errorLabel?
- If the last error was retryable, why was a retry not performed? Was the retry budget depleted (
DRIVERS-3240)? Did we hit the max retry attempts? - How long did the failed operation take (including all retries)?
- depends on
-
SERVER-108583 Add diagnostic metadata to identify retried commands
-
- Backlog
-
- is related to
-
SERVER-108583 Add diagnostic metadata to identify retried commands
-
- Backlog
-
-
DRIVERS-3239 Exponential backoff and jitter in retry loops
-
- In Progress
-
-
DRIVERS-3240 Adaptive token bucket retry policy
-
- Closed
-