AbortedException from client logged at ERROR level with WebFlux functional endpoint

[mv-shallow]

Version: org.springframework.boot:spring-boot-starter-webflux:3.5.8 / org.springframework:spring-web:6.2.14

I have a service that uses Reactor Netty.

When client closes connection before sending full request body there is a log with ERROR level:

2026-05-18T14:22:17.887+03:00 ERROR 9144 --- [tor-http-nio-11] o.s.w.s.adapter.HttpWebHandlerAdapter    : [e8392712-7] 500 Server Error for HTTP POST "/test"

reactor.netty.channel.AbortedException: Connection has been closed
	at reactor.netty.http.server.HttpServerOperations.onInboundClose(HttpServerOperations.java:931) ~[reactor-netty-http-1.2.12.jar:1.2.12]
	Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: 
Error has been observed at the following site(s):
	*__checkpoint ? HTTP POST "/test" [ExceptionHandlingWebHandler]
Original Stack Trace:
		at reactor.netty.http.server.HttpServerOperations.onInboundClose(HttpServerOperations.java:931) ~[reactor-netty-http-1.2.12.jar:1.2.12]

Which is a bit unexpected since it's a client-side issue related to connection, so there is seemingly no need for it to be logged as ERROR by default and have any status code. (Also undesirable because in my case there are alerts configured for any logs with ERROR level)

I'd expect it to be logged at WARN/DEBUG/TRACE and this line does exactly that, but checkAndLogClientDisconnectedException isn't executed since response.setStatusCode(HttpStatus.INTERNAL_SERVER_ERROR) returns true.

This looks like a bug since the code for "expected" behavior is there but is unreachable. If it's not a bug or a limitation of connectivity-related error handling, how can I safely provide my own handling for such case, via ExceptionHandler?

Below are some snippets for reproducing this issue

Main.java:

@SpringBootApplication
public class Main {
    public static void main(String[] args) {
        SpringApplication.run(Main.class, args);
    }

    @Bean
    RouterFunction<?> routerFunction() {
        return RouterFunctions
            .route()
            .POST(
                "/test",
                request -> request
                    .bodyToMono(String.class)
                    .flatMap(body -> ServerResponse.ok().build())
            ).build();
    }
}

build.gradle:

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.5.8'
    id 'io.spring.dependency-management' version '1.1.7'
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-webflux'
}

python script for producing aborted request:

import socket

HOST = "127.0.0.1"
PORT = 8080

request = (
    b"POST /test HTTP/1.1\r\n"
    b"Host: localhost\r\n"
    b"Content-Type: text/plain\r\n"
    b"Content-Length: 2\r\n"
    b"\r\n"
)

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((HOST, PORT))
sock.sendall(request)
sock.sendall(b"A")
sock.close()

[suuuuuuminnnnnn]

i can take this on. i’ll work on a minimal fix + regression test to ensure client disconnect exceptions are handled without being logged as 500 server errors. i’ll report back with a pr once i have a reliable repro and verification.

[bclozel]

This is also being discussed in #34481

[rstoyanchev]

The original idea was that it's safer to check whether the response is still possible to set, and that it wouldn't be the case if the connection is lost. As is obvious under #34481 in some cases it's not possible to correctly differentiate whether the lost connection is to the client or to an onward connection to another remote.

For consistency with the plan in #34481, we should continue to do this, i.e. try to set the response to 500 if it is possible, but at the same avoid error logging if the error is identified as a client connection issue. On the small chance that it is a misidentified onward connection, the status would still be correct.