You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Resilience4j version: 1.1.0 and 1.2.0
Java version: 8
Problem description:
I noticed that an original exception handled by RetryOperator is wrapped by RetryExceptionWrapper.
In my case the code is something like below:
public class BusinessService {
private ExampleWebClient exampleWebClient;
public Mono<String> doSomething() {
return exampleWebClient.doSomething()
.doOnError(BusinessException.class, e -> {
// log business exception
})
.doOnError(RetryExceptionWrapper.class, e -> {
// this block is executed but BusinessException is expected
})
.doOnError(e -> {
// log other exceptions
});
}
}
The above service calls a web client which is annotated with @Retry
@Retry(name = "exampleConfig")
public class ExampleWebClient {
private WebClient webClient; // spring reactive web client
public Mono<String> doSomething() {
return webClient
.get()
.uri("/exampleEndpoint")
.retrieve()
.bodyToMono(String.class)
.onErrorMap(WebClientResponseException.class, e -> new BusinessException());
}
}
Not sure if this is expected behaviour but my understanding is that retry should be executed behind the scene and should not affect the reactor flow, i.e. removing or adding @Retry annotation should not change the type of exception received by the service class.
It may be worth mentioning that the BusinessException is added to ignoreExceptions.
Please let me know what do you think about this.
Thanks,
Adam.
The text was updated successfully, but these errors were encountered:
Resilience4j version: 1.1.0 and 1.2.0
Java version: 8
Problem description:
I noticed that an original exception handled by RetryOperator is wrapped by RetryExceptionWrapper.
In my case the code is something like below:
The above service calls a web client which is annotated with
@Retry
Not sure if this is expected behaviour but my understanding is that retry should be executed behind the scene and should not affect the reactor flow, i.e. removing or adding
@Retry
annotation should not change the type of exception received by the service class.It may be worth mentioning that the BusinessException is added to ignoreExceptions.
Please let me know what do you think about this.
Thanks,
Adam.
The text was updated successfully, but these errors were encountered: