FT: Retry policy not reporting original Exception (cause) on timeout
See original GitHub issueEnvironment Details
- Helidon Version: 2.3.0
- Helidon MP
- JDK version: 11
- OS: Linux
- Docker version (if applicable):
Problem Description
When an exception occurs with Retry FT policy and the processing time surpasses the overall timeout, the original cause is never reported.
Steps to reproduce
Retry.builder()
.retryPolicy(Retry.JitterRetryPolicy.builder().build())
.overallTimeout(Duration.ofSeconds(1))
.build().invoke(() -> CompletableFuture.runAsync(() -> {
try {
Thread.sleep(2000);
throw new RuntimeException("Hello");
} catch (InterruptedException e) {
e.printStackTrace();
}
})).exceptionallyAccept(Throwable::printStackTrace).toCompletableFuture().join();
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
DefaultRetryPolicy (DataStax Java Driver for Apache Cassandra
This policy retries queries in only two cases: On a read timeout, retries once on the same host if enough replicas replied but...
Read more >Attempt timeouts causing non-retryable AbortedExceptions
Possible Solutions. Catch AbortedException s that are caused by the thread being interrupted when an API call attempt times out and re-throw an ......
Read more >Microprofile Fault Tolerance
The timeout is restarted for each retry. If @Asynchronous is also used and the retry is the result of a TimeoutException , the...
Read more >Retry multiple times when http request times out using polly c# ...
1 Answer 1 · Note that if the timeout of the client is too close to the policy timeout it might still fail...
Read more >Error Codes and Descriptions - Travelport
0014, Unsuccessful host transaction causing partial failure. ... 19058, Universal Policy is not supported prior to version 15.4 (hotel.xsd v34).
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Check out #3449.
If this should be the case than this is not how the policy currently behaves. Try removing the runtime exception from above and raising the sleep to like 5s - the execution will go on and finish successfully even though the execution time surpasses the overall timeout by a lot.
However, my point was that in case the execution does end up with an exception, but it happens after the overall timeout is reached, the original exception is gone and will never see it in the logs. I want to see the original exception no matter what happens.