[Idea] Retry - throw on max retries reached

Resilience4j version: 1.6.1

Java version: openjdk 15 2020-09-15

Here’s a feature suggestion which I would gladly open a PR for: Whenever the Retry logic reaches it’s configured maxAttempts, it would be nice for a configurability option to throw an exception, instead of returning the last result back to the caller.

I found it unintuitive to configure a retryOnResult, only to find out that after maxAttempt was reached, the result was still being returned. In my mind, if you consider a certain result an error to be retried, it doesn’t suddenly become a non-error just cause you ran out of retries 😃

This probably depends on the use-case though, but having some kind of throwOnCompletion or throwOnMaxFailedRetries configuration would be awesome.

Here’s my use case:

final Retry retry = Retry.of("clientCall", RetryConfig
    .<HttpResponse<String>>custom()
    .retryOnException(e -> e instanceof IOException)
    .retryOnResult(response -> response.statusCode() == 503)
    .build()
);

final HttpResponse<String> resp = retry.executeCheckedSupplier(() -> client.send(
    request, HttpResponse.BodyHandlers.ofString()
));

return resp.body();

resp would still be the last attempts response, even though retryOnResult would have kicked in.

My suggestion would be to config it up like:

final Retry retry = Retry.of("clientCall", RetryConfig
    .<HttpResponse<String>>custom()
    .retryOnException(e -> e instanceof IOException)
    .retryOnResult(response -> response.statusCode() == 503)
->  .throwOnMaxFailedRetries(response -> new RuntimeException("Call failed, retries exhausted. status=" + response.statusCode()))
    .build()
);

Which would make retry.executeCheckedSupplier() throw the configured exception, if the result still matches the retryPredicate.

What do you think about this?

[RobWin]

Yes, throwing a MaxRetriesExceeded exception would be a breaking change. But keep in mind that the event consumer might run in a different thread than your function, if you would use a CompletableFuture. It’s more of a workaround than a solution 😦 I would prefer your initial proposal.

[RobWin]

Hi, sry for the late response. We were on vacation.

I like the idea. But If you would like to provide a PR, please take care that the reactive modules like Reactor, RxJava2 and RxJava3 are also modified and tested.