Conversation
jrhee17
left a comment
There was a problem hiding this comment.
Looks good overall 👍 Left some minor questions 🙏
| public AbstractRuleBuilder onResponseTimeout() { | ||
| return onException((ctx, ex) -> { | ||
| if (ex instanceof UnprocessedRequestException) { | ||
| return ex.getCause() instanceof TimeoutException; |
There was a problem hiding this comment.
Question) Couldn't ctx.isTimedOut() still be true?
| return ex.getCause() instanceof TimeoutException; | |
| ex = ex.getCause(); |
There was a problem hiding this comment.
Question) Couldn't ctx.isTimedOut() still be true?
No, it isn't. It is listed in the TODO on #4876 (comment)
There was a problem hiding this comment.
(TODO)
CancellationScheduler.finishNow(TimeoutException)onsession/connection timeoutto setctx.isTimeOut=true
(Checked with ikhoon nim before) currently I think session/connection timeout doesn't set ctx.isTimeout=true, so I plan to fix it with next PR~!
jrhee17
left a comment
There was a problem hiding this comment.
Left a minor question but looks good to me 👍 Thanks @injae-kim 🙇 👍 🚀
| return ex instanceof UnprocessedRequestException && | ||
| ex.getCause() instanceof TimeoutException; |
There was a problem hiding this comment.
Question since I'm not sure either) Do we also want to check for cases where a TimeoutException is thrown directly from a upstream decorator? e.g. ConcurrencyLimitTimeoutException
| return ex instanceof UnprocessedRequestException && | |
| ex.getCause() instanceof TimeoutException; | |
| return ex instanceof TimeoutException || | |
| ex instanceof UnprocessedRequestException && | |
| ex.getCause() instanceof TimeoutException; |
Ignore this comment 😅
There was a problem hiding this comment.
Shouldn't we do this? If users manually complete the response exceptionally with a ResponseTimeoutException from a decorator, it wouldn't work.
This might also confuse users that onTimeoutException() is invoked only when the exception is wrapped with the UnprocessedRequestException even though it isn't.
There was a problem hiding this comment.
If users manually complete the response exceptionally with a ResponseTimeoutException from a decorator, it wouldn't work.
oh~ this case can happen. @ikhoon nim, WDYT? (how about check ex instanceof TimeoutException too?)
There was a problem hiding this comment.
If users manually complete the response exceptionally with a ResponseTimeoutException from a decorator, it wouldn't work.
Hmm... ResponseTimeoutException is a special exception to cancel a response based on the timeout stored in ctx.responseTimeoutMillis(). If a user raises ResponseTimeoutException, it should be assumed as a normal exception but neither a timeout exception or a cancellation exception.
This might also confuse users that onTimeoutException() is invoked only when the exception is wrapped with the UnprocessedRequestException even though it isn't.
If we update the contract of ctx.isTimedOut() properly, I don't see users get confused of the behavior. They may not judge the behavior by the implementation.
Anyway, it is good to add ex instanceof TimeoutException in this PR because ctx.isTimedOut() doesn't cover WriteTimeoutException and ConcurrencyLimitTimeoutException even though we will handle them in the following PR.
Let's make this PR solid itself.
There was a problem hiding this comment.
Anyway, it is good to add ex instanceof TimeoutException in this PR
✅ updated!
minwoox
left a comment
There was a problem hiding this comment.
Looks great all in all. 👍
Left just a small opinion.
| return ex instanceof UnprocessedRequestException && | ||
| ex.getCause() instanceof TimeoutException; |
There was a problem hiding this comment.
Shouldn't we do this? If users manually complete the response exceptionally with a ResponseTimeoutException from a decorator, it wouldn't work.
This might also confuse users that onTimeoutException() is invoked only when the exception is wrapped with the UnprocessedRequestException even though it isn't.
minwoox
left a comment
There was a problem hiding this comment.
Looks good all in all, thanks a lot! @injae-kim
BTW, could you revise the title and the description of this PR? 😄
onResponseTimeout() on RetryRule and CircuitBreakerRuleonTimeoutException() on RetryRule and CircuitBreakerRule
|
oh~ I updated PR title&desc, |
…4882) Motivation: It would be useful to provide a way to configure retry and circuit breaker rules to trigger than a request is timed out, before fully receving a response. Modifications: - Add `.onTimeoutException()` to `RetryRule` and `CircuitBreakerRule` Result: - You can use `.onTimeoutException()` on RetryRule and CircuitBreakerRule when a request is timed out before fully receiving a response. - Closes line#4876
Motivation:
It would be useful to provide a way to configure retry and circuit breaker
rules to trigger than a request is timed out, before fully receving a response.
Modifications:
.onTimeoutException()toRetryRuleandCircuitBreakerRuleResult:
.onTimeoutException()on RetryRule and CircuitBreakerRule when a request is timed out before fully receiving a response.RetryRule.onResponseTimeout()#4876PRs Overview
onTimeoutException()toRetryRuleandCircuitBreakerRuletoCancellationScheduler.finishNow(TimeoutException)on session/connection timeout to setctx.isTimeOut=true