As documented in https://github.com/mmanciop/response-status-repro, @ResponseStatus does not work out of the box with WebFlux applications, but ResponseStatusException does.
I think ResponseStatusException works and not @ResponseStatus due to org.springframework.boot.web.reactive.error.DefaultErrorAttributes#determineHttpStatus and other methods.
I truly cannot tell if this is by design or by oversight. Would it make sense for me to open a PR and add @ResponseStatus support to org.springframework.boot.web.reactive.error.DefaultErrorAttributes?
I've dug into this a bit after upgrading the demo application to 2.1 and I think we have an ordering issue. Our DefaultErrorWebExceptionHandler is currently ordered -1 which means it ends up running before WebFluxResponseStatusExceptionHandler. This means the status detection logic never finds the correct code.
@bclozel What's the impact if we change the order at this stage?
Created a PR just in case it turns out it is better to just implement the support for @ResponseStatus in DefaultErrorWebExceptionHandler side-by-side with the support for ResponseStatusException.
@philwebb The ordering issue is actually intentional.
Our own org.springframework.web.server.WebExceptionHandler implementation, DefaultErrorWebExceptionHandler is ordered before the WebFlux one, because it has to handle all errors and render views/payloads for them and not delegate to the following ones.
This means we have to keep in sync and replicate what happens in Spring WebFlux - in this case, I missed SPR-16567 and we have to backport that into our own implementation.
I'm closing this issue in favor of #14744
Thanks @mmanciop !
Most helpful comment
@philwebb The ordering issue is actually intentional.
Our own
org.springframework.web.server.WebExceptionHandlerimplementation,DefaultErrorWebExceptionHandleris ordered before the WebFlux one, because it has to handle all errors and render views/payloads for them and not delegate to the following ones.This means we have to keep in sync and replicate what happens in Spring WebFlux - in this case, I missed SPR-16567 and we have to backport that into our own implementation.
I'm closing this issue in favor of #14744
Thanks @mmanciop !