Discard remaining REST handlers when the client connection is closed prematurely

[geoand]

• Relates to: TraceId not available in logs following client timeout in REST call #50958

P.S. This is a breaking change because there might be code out there that depends on the side effects of various handlers always running (like code in response filters)

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 61d1b10.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[FroMage]

Meh. I don't think there's any expectation that response handlers run when the connection is closed. In fact I doubt this is even defined or specified.

There could be people asking for callbacks to be run after the connection closes, for cleanup. Like, making sure the TX is rolled back (but this happens in interceptors, so that should not be interrupted and complete, even with this change, which only skips the remaining steps, it does not interrupt any running one), or closing connections to the DB perhaps?

I'm not entirely sure what sort of handlers we have after the endpoint, and whether we can afford to skip them on connection loss. Do you have any sample?

[FroMage]

Heh, I was going to say exactly the same thing. I'm impressed.

I'm not sure what thread invokes the close handler (I guess/hope the same request's context/thread) and what other thread might be running the request (especially in the case of blocking requests).

So this might indeed have more than one thread interact with the handler position in parallel. Needs to be checked.

[geoand]

I don't think there's any expectation that response handlers run when the connection is closed. In fact I doubt this is even defined or specified.

Agreed

Like, making sure the TX is rolled back (but this happens in interceptors, so that should not be interrupted and complete, even with this change, which only skips the remaining steps, it does not interrupt any running one), or closing connections to the DB perhaps?

Sure, but those are not REST handlers and would likely be handled in a different way

I'm not entirely sure what sort of handlers we have after the endpoint, and whether we can afford to skip them on connection loss. Do you have any sample?

Most prominent are ResponseHandler, ResponseWriterHandler ResourceResponseFilterHandler

[FroMage]

Yeah, those should be fine.