-
Notifications
You must be signed in to change notification settings - Fork 38.6k
Description
Overview
When the core retry functionality was introduced (see #34716), it had a built-in MaxRetryDurationPolicy
. In #35058, that was migrated to a withMaxDuration()
factory method, and in #35110 that was renamed to withMaxElapsedTime()
(with a corresponding maxElapsedTime()
method on the builder) in order to align with the maxElapsedTime
feature of ExponentialBackOff
. The latter also changed the semantics of the feature in the context of the RetryPolicy
(see below).
However, @Retryable
does not provide maxElapsedTime
support.
In addition, the maxElapsedTime
feature is a bit misleading, since it does not actually track CPU time or wall-clock time but rather only the sum of individual, accumulated back-off intervals/delays, which is likely not very useful. Furthermore, the maxElapsedTime
will never apply to a zero-valued delay/interval.
In light of the above, we should remove maxElapsedTime
support from the built-in RetryPolicy
.
Users can still implement a custom BackOff
strategy if they find they need some form of "max elapsed time" or "max duration".