Open
Description
Motivation
If a user wants to construct a caching RetryConfigMapping
, they can currently do so by:
- Subclassing
RetryConfigMapping
, or - Using
RetryConfigMapping.of( BiFunction<? super ClientRequestContext, Request, String> keyFactory, BiFunction<? super ClientRequestContext, Request, RetryConfig> mapping )
It is quite common for users of a RetryClient
or RpcRetryClient
to configure retry behavior on a per-method, per-path, or per-host basis. However, the current options force users who want their configs to be cached to either:
- Create their own abstraction to support per-* configuration + caching, or
- Use
RetryConfigMapping.of
where they need to provide akeyFactory
which extracts the method, host or path.
This contrasts with the configuration of circuit breaking, where CircuitBreakerMapping
provides dedicated methods like .perMethod()
, .perHost()
, and .perPath()
for this purpose.
Solution
In this issue we smooth out RetryConfigMapping
to offer the same API as CircuitBreakerMapping
, to improve developer experience and ensure consistency between the two configuration mechanisms.
Metadata
Metadata
Assignees
Labels
No labels