enum RetryTimeDiscriminants {
Immediate,
AfterWaiting,
After,
At,
Never,
}
Expand description
Auto-generated discriminant enum variants
Variants§
Immediate
The operation can be retried immediately, and no delay is needed.
The recipient of this RetryTime
variant may retry the operation
immediately without waiting.
This case should be used cautiously: it risks making code retry in a loop without delay. It should only be used for error conditions that are necessarily produced via a process that itself introduces a delay. (For example, this case is suitable for errors caused by a remote timeout.)
AfterWaiting
The operation can be retried after a short delay, to prevent overloading the network.
The recipient of this RetryTime
variant should delay a short amount of
time before retrying. The amount of time to delay should be randomized,
and should tend to grow larger the more failures there have been
recently for the given operation. (The RetryDelay
type from
tor-basic-utils
is suitable for managing this calculation.)
This case should be used for problems that tend to be “self correcting”, such as remote server failures (the server might come back up).
After
The operation can be retried after a particular delay.
The recipient of this RetryTime
variant should wait for at least the
given duration before retrying the operation.
This case should only be used if there is some reason not to return
AfterWaiting
: for example, if the implementor is providing their own
back-off algorithm instead of using RetryDelay.
(This is a separate variant from At
, since the constructor may not
have convenient access to (a mocked view of) the current time. If you
know that the current time is now
, then After(d)
is equivalent to
At(now + d)
.)
At
The operation can be retried at some particular time in the future.
The recipient of this this RetryTime
variant should wait until the
current time (as returned by Instant::now
or SleepProvider::now
as
appropriate) is at least this given instant.
This case is appropriate for when we have a failure condition caused by waiting for multiple other timeouts. (For example, if we believe that all our guards are down, then we won’t be able to try getting a guard until the next time guard is scheduled to be marked as retriable.)
Never
Retrying is unlikely to make this operation succeed, unless something else is fixed first.
The recipient of this RetryTime
variant should generally give up, and
stop retrying the given operation.
We don’t mean “literally” that the operation will never succeed: only that retrying it in the near future without fixing the underlying cause is unlikely to help.
This case is appropriate for issues like misconfiguration, internal errors, and requests for operations that the network doesn’t support.
This case is also appropriate for a problem that is “technically” retriable, but where any resolution is likelier to take days or weeks instead of minutes or hours.
Trait Implementations§
Source§impl Clone for RetryTimeDiscriminants
impl Clone for RetryTimeDiscriminants
Source§fn clone(&self) -> RetryTimeDiscriminants
fn clone(&self) -> RetryTimeDiscriminants
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read more