-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Make Gateway return 504 when HttpClient times out #558
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| responseFlux = responseFlux.timeout(properties.getResponseTimeout(), | ||
| Mono.error(new TimeoutException("Response took longer than timeout: " + | ||
| properties.getResponseTimeout()))); | ||
| properties.getResponseTimeout()))).onErrorMap(TimeoutException.class, th -> new ResponseStatusException(HttpStatus.GATEWAY_TIMEOUT, null, th)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, here one may say "Hey, why don't we get rid of TimeoutException altogether then"?
The answer is: it is a very convenient "marker" exception, which I already make use of in #555. I like the fact that, by not reusing java.util.concurrent.TimeoutException, one can tell apart this type of timeout from one issued, for example, by a filter using java.util.concurrent.Future for whatever dastardly reasons.
Codecov Report
@@ Coverage Diff @@
## master #558 +/- ##
============================================
+ Coverage 70.69% 70.69% +<.01%
Complexity 930 930
============================================
Files 129 129
Lines 3672 3662 -10
Branches 263 263
============================================
- Hits 2596 2589 -7
+ Misses 938 935 -3
Partials 138 138
Continue to review full report at Codecov.
|
|
Similarly to #557, I moved the PR to 2.x . Do we want to treat this as a breaking change and target only the next release (G... Grubsomething? :D). If we want to ship it only with the next release, I'll gladly move this back to master. |
|
Nevermind, it is a breaking change due to the change in status code. Well-behaving REST clients should not break because of a change from |
When the underpinning Netty
HttpClienttimes out (based, e.g., on the value ofspring.cloud.gateway.httpclient.responseTimeout), the Gateway returns500to its client instead of504.This change wraps the
org.springframework.cloud.gateway.support.TimeoutExceptionthrown upon the timeout with aorg.springframework.web.server.ResponseStatusExceptionthat sets the status code to504.As an added boon, using
org.springframework.web.server.ResponseStatusExceptionthis way enables the usual error handling mechanisms (error white-page, error attributes) for this type of failure.