-
Notifications
You must be signed in to change notification settings - Fork 38.8k
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".