Description
This issue a follow-up issue to #20865.
In #20865, the negotiated content-type during the request mapping phase would impact the content type chosen for the @ExceptionHandler error response instead of restarting the content negotiation phase. This has been fixed by removing the negotiated content type before handling errors.
In this case, the negotiated content type information is kept in a different place.
When setting up the reactive pipeline with the chosen EncoderHttpMessageWriter, the response content type is set before the subscription happens. Later when the returned value from the error handling phase is handled in HandlerResultHandlerSupport.selectMediaType, the response content-type is already set and chosen directly.
The only difference with #20865 is that the content type is set before the subscription happens and is not cleared before handling the error response.