Spring-boot: WebFlux: @ResponseStatus does not work out of the box, but ResponseStatusException does

Created on 9 Oct 2018  路  3Comments  路  Source: spring-projects/spring-boot

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?

superseded

Most helpful comment

@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 !

All 3 comments

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 !

Was this page helpful?
0 / 5 - 0 ratings