Affects: both 5.3.25, 6.0.6 but differently

I have almost the same process like described in #29038: Service returns Flux<SomeObject> which is then returned by controller as ResponseEntity.ok(payloadFlux). If any error occurs it triggers either ResponseStatusException or some custom Exception. I noticed different behaviour between versions 5 and 6 in the case if flux contains error after some element. There are three options for non empty flux: * flux completes successfully after some elements * works as expected in both versions, server returns 200 * flux has error without any elements * works as expected in both versions, server returns status from exception * flux has error after some elements * works differently * version 5: server returns status from exception * version 6: server starts to stream response with status 200 and first element and can not change the status afterwards: Error [org.springframework.web.server.ResponseStatusException] for HTTP GET "/path", but ServerHttpResponse already committed (200 OK) Error finishing response. Closing connection * it only affects JSON payload, if payload is Flux<String> both versions behave like with JSON payload in version 6: unable to set correct error status because response is already commited with status 200

Example project: * run with mvn clean verify: * two failed tests * change parent version to spring boot 2.7.9, which depends on spring-webflux 5.3.25 and run again: * only test with string payload fails

webflux-flux-response-with-error.zip

Comment From: alex-arana

I've refreshed @denvir 's test harness for the latest releases of Spring Boot / WebFlux and can confirm the issue is very much still there. You can find my test repository here:

https://github.com/alex-arana/webflux-flux-response-with-error

Comment From: rstoyanchev

This is a side effect of #28398 where Flux is written as a stream vs collecting items to a List first. The idea is that as a framework we don't know how many items will be written, and it's better to stream the output rather than aggregating into a potentially very large list. You can still achieve the same effect by returning Mono<List<T>> with flux.collectList().