Flush pending writes before closing the connection on caught exceptions

[asalajan]

Fixes #6155

Motivation:

When an exception is caught on a connection, VertxHandler#exceptionCaught dispatches the throwable to the user handlers and then closes the channel with chctx.close(). A response written from the handler -- for instance a 400 written from request().exceptionHandler() when HttpContentDecompressor throws a DecoderException on a malformed compressed body -- is enqueued in the outbound message queue but not flushed, because VertxConnection#write skips the flush while a read is in progress. chctx.close() then causes Netty to discard the unflushed entries from the ChannelOutboundBuffer, so the response never reaches the client: the client observes a connection reset instead of the intended HTTP response.

Changes:

Route the exception-driven close through the channel so it traverses the pipeline tail and invokes VertxHandler#close -> VertxConnection#writeClose, which flushes pending writes (an empty buffer with forceFlush=true) and closes the channel only once the flush has completed. This is the same flush-then-close path already used by graceful shutdown, idle close and the regular close(); the exception path simply was not using it. The bare chctx.close() is kept as a fallback for the case where no connection has been set yet (handlerAdded has not run), since VertxHandler#close dereferences it.

Add a regression test, Http1xTest#testRequestDecompressionInvalidBodyDeliversErrorResponse, that sends a malformed gzip body to a server with decompression enabled and asserts the client receives the response written from the request exception handler.

HTTP/2 is unaffected: its codec replaces VertxHandler in the pipeline, so connection-level exceptions do not go through this path.

I'm happy to open the backport PRs for version 5.0.x and 5.1.x once this one is reviewed/merged

Developed with assistance from an AI coding agent (Claude Code). I reviewed and tested the changes.

[vietj]

for this fix we need a test in VertxConnectionTest that reproduces the situation as well.

[asalajan]

for this fix we need a test in VertxConnectionTest that reproduces the situation as well.

I have added testFlushPendingWriteOnExceptionClose() in VertxConnectionTest

[asalajan]

Hello @vietj !
Is there anything that still needs addressing for this PR ?

[vietj]

@asalajan as I understand we are testing the behavior using the NetClient communication to the HTTP server ?

[asalajan]

@vietj Yes, for testRequestDecompressionInvalidBodyDeliversErrorResponse, raw NetClient is used to capture the response bytes directly and assert the 400 reaches the wire before the connection closes which is the exact behaviour the fix restores.
A HttpClient version would work too, but NetClient gives a direct signal (empty buffer vs. the full HTTP/1.1 400) without going through the client HTTP stack.

For the second test, testFlushPendingWriteOnExceptionClose, EmbeddedChannel is used to isolate the change from the HTTP/decompression specifics

[asalajan]

@vietj I've edited my previous response to try to clarify why NetClient was used.

[vietj]

I would like actually this test to be in NetClientTest and avoid make it an HTTP test because it is not related to HTTP protocol

[asalajan]

I would like actually this test to be in NetClientTest and avoid make it an HTTP test because it is not related to HTTP protocol

@vietj I moved the test. Please let me know if you see any other issues.

[asalajan]

I see 3 WebSocket tests are failing because of this change. I missed running them locally:

Error:  Errors: 
Error:    WebSocketTest.testReportProtocolViolationOnClient » Timeout Unsatisfied checkpoint
Error:    WebSocketTest.testReportProtocolViolationOnServer » Timeout Unsatisfied checkpoint
Error:    WebSocketTest.testServerWebSocketExceptionHandlerIsCalled » Timeout Unsatisfied checkpoint
Error:  Tests run: 6770, Failures: 0, Errors: 3, Skipped: 142

They pass on master and fail with the fix with both the unconditional and the earlier guarded form - anything that reaches VertxHandler.close.

I am not familiar with WebSockets but I can try to look into it more with the help of AI.

Maybe one option could be to narrow the fix to the HTTP/1 layer by flushing the response in the server connection exception handling before close, and VertxHandler.exceptionCaught remains as it is: chctx.close(). I don't know if a generic protocol agnostic solution exists.

[vietj]

@asalajan I will have a look myself