Smallrye Fault tolerance and RestEasy Rest Client

[gquintana]

Two questions related to Smallrye fault tolerance when applied on a RESTEasy REST client:

1. Are there some sensible defaults regarding on which exceptions to retry or abort? How can I know which exceptions may be raised by the REST Client? I'd like to retry when I have networking issues (ConnectException and similar) but not on all HTTP server exceptions (HTTP status 4xx and 5xx). How can I tell them apart?
2. Is it possible to apply fault tolerance as a global JAXRS Client interceptor/filter? Is it possible to avoid adding annotations on all REST client interfaces and apply a global strategy?

[quarkus-bot[bot]]

/cc @Ladicek (fault-tolerance,smallrye), @cescoffier (rest-client), @geoand (rest-client), @jmartisk (smallrye), @phillip-kruger (smallrye), @radcortez (smallrye)

[Ladicek]

I don't know exactly how to figure out what exceptions the RestClient may throw, but it seems fairly likely they are going to be subtypes of WebApplicationException.

It is possible to use SmallRye Fault Tolerance globally, with the programmatic API (no annotations). I'm no JAX-RS expert, so I don't really know if the JAX-RS Client API provides the necessary hooks, but I guess it should be doable.

[gquintana]

Effectively, for the second part of the question:

@Provider
@ConstrainedTo(RuntimeType.CLIENT)
public class RetryInterceptor implements ReaderInterceptor {
    static final FaultTolerance<Object> retrier = FaultTolerance.create()
            .withRetry()
                .maxRetries(3)
                .delay(3, ChronoUnit.SECONDS)
                .maxDuration(1, ChronoUnit.MINUTES)
                .abortOn(WebApplicationException.class)
                .done()
            .build();

    @Override
    public Object aroundReadFrom(ReaderInterceptorContext readerInterceptorContext) throws IOException, WebApplicationException {
        try {
            return retrier.call(readerInterceptorContext::proceed);
        } catch (IOException|WebApplicationException e) {
            throw e;
        } catch (Exception e) {
              throw new RuntimeException("Retry interceptor failure", e);
        }
    }
}

Thanks for your pointer on programmatic API!

For the first of the question, WebApplicationException convers all HTTP level errors, does it? The client got a response from the server but the HTTP status meant an error?

[Ladicek]

Yes, WebApplicationException should cover for non-200 HTTP responses. I should have mentioned that other errors, such as IO errors, are likely to be covered by different exceptions. Often, JAX-RS client exceptions are wrapped, which might require extra care.

[gquintana]

The above ReaderInterceptor does not work. A complete CDI interceptor is needed, which requires adding an annotation to generated REST client interface. So I guess the answser to question 2 is no, it is not possible.

I had to tweek the OpenAPI generator templates to add @Retry annotation in generated code. I noticed an @CircuitBreaker annotation was already present in template: https://github.com/quarkiverse/quarkus-openapi-generator/blob/main/deployment/src/main/resources/templates/libraries/microprofile/api.qute#L69C2-L73C16 Why @CircuitBreaker and not @Retry nor @Timeout