Creates a new RetryPolicy based on the current RetryPolicy in which values of A are first checked against a predicate function, and only if the predicate returns true will the value be passed on to the current RetryPolicy.

The predicate function need not be a pure function, but can change its behavior over time. For example, the predicate function's decision can be based upon backpressure signals supplied by things like failure rates or latency, which allows RetryPolicys to dynamically reduce the number of retries in response to backpressure.

The predicate function is only called on the first failure in a chain. Any additional chained RetryPolicies returned by the current policy will then see additional failures unfiltered. Contrast this will filterEach, which applies the filter to each RetryPolicy in the chain.

Similar to filter, but the predicate is applied to each RetryPolicy in the chain returned by the current RetryPolicy. For example, if the current RetryPolicy returns Some((D, P')) for value E (of type A), and the given predicate returns true for E, then the value returned from the filtering RetryPolicy will be Some((D, P)) where P is equal to P'.filterEach(pred).

One example where this is useful is to dynamically and fractionally allow retries based upon backpressure signals. If, for example, the predicate function returned true or false based upon a probability distribution computed from a backpressure signal, it could return true 50% of the time, giving you a 50% chance of performing a single retry, a 25% chance of performing 2 retries, 12.5% chance of performing 3 retries, etc. This might be more desirable than just using filter where you end up with a 50% chance of no retries and 50% chance of the full number of retries.

Applies a dynamically chosen retry limit to an existing RetryPolicy that may allow for more retries. When the returned RetryPolicy is first invoked, it will call the maxRetries by-name parameter to get the current maximum retries allowed. Regardless of the number of retries that the underlying policy would allow, it is capped to be no greater than the number returned by maxRetries on the first failure in the chain.

Using a dynamically chosen retry limit allows for the retry count to be tuned at runtime based upon backpressure signals such as failure rate or request latency.