in amazon-qldb-driver-core/src/retry.rs [81:123]
fn on_err(&self, error: &QldbError, attempt_number: u32) -> RetryInstructions {
match error {
QldbError::SdkError(e) => {
let should_retry = match &e {
SdkError::ServiceError {
err: SendCommandError { kind, .. },
..
} => match kind {
SendCommandErrorKind::BadRequestException(_) => false,
SendCommandErrorKind::InvalidSessionException(_) => true,
SendCommandErrorKind::LimitExceededException(_) => false,
SendCommandErrorKind::OccConflictException(_) => true,
SendCommandErrorKind::RateExceededException(_) => false,
SendCommandErrorKind::CapacityExceededException(_) => true,
SendCommandErrorKind::Unhandled(_) => false,
_ => false,
},
// Construction failures mean that the sdk has rejected the
// request shape (e.g. violating client-side constraints).
// There is no point retrying, since the sdk will simply
// reject again!
SdkError::ConstructionFailure(_) => false,
// We retry dispatch and timeout failures even though the request *may*
// have been sent. In QLDB, the commit digest protects
// against a duplicate statement being sent.
SdkError::DispatchFailure(_) | SdkError::TimeoutError(_) => true,
SdkError::ResponseError { raw, .. } => match raw.http().status().as_u16() {
500 | 503 => true,
_ => false,
},
};
if !should_retry || attempt_number > self.max_attempts {
return RetryInstructions::dont();
} else {
let delay =
exponential_backoff_with_jitter(self.base, self.cap, attempt_number);
return RetryInstructions::after(Duration::from_millis(delay as u64));
}
}
_ => return RetryInstructions::dont(),
}
}