Reorder Grpc server interceptors to apply exception handler correctly

[ozangunalp]

Fixes #39602

To squash once reviewed

[ozangunalp]

@alesj I am not sure if this breaks anything. Please take a look

[alesj]

@ozangunalp so this looks like we had the interceptors order wrong all along?
@cescoffier ^^ ?!

[alesj]

The tests seem to pass locally

• https://gist.github.com/alesj/425fce74784e50f638794fb86c5b1730

[ozangunalp]

@ozangunalp so this looks like we had the interceptors order wrong all along? @cescoffier ^^ ?!

Yes, the blocking interceptor schedules server listener calls on other threads so there wasn't any other way to apply the exception handling. The solution is to apply the blocking interceptor before the exception handling, so when an exception is thrown by the server method it gets handled by the handler and we close the server call by setting the status.

Where we need to pay attention in this change is all the other places I moved the list of interceptors. Sure tests pass but I am not sure whether we need to test something else.

[cescoffier]

Yes, it may break users interceptor, but I think this change makes a lot of sense.

[ozangunalp]

I am squashing it and it's good to go then

[alesj]

Yes, it may break users interceptor, but I think this change makes a lot of sense.

Break them in what way?

[quarkus-bot]

Status for workflow Quarkus CI

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

✅ 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.

[ozangunalp]

Yes, it may break users interceptor, but I think this change makes a lot of sense.

Break them in what way?

Expecting to get called in event loop but getting called on worker thread. But at least the context will be preserved.

[alesj]

Expecting to get called in event loop but getting called on worker thread. But at least the context will be preserved.

Don't we / you control this with the @Blocking / @RunOnVirtualThread ... ?

Or this has changed now by default, and if someone is depending on this impl-details, it will break the current interceptors?

[ozangunalp]

Expecting to get called in event loop but getting called on worker thread. But at least the context will be preserved.

Don't we / you control this with the @Blocking / @RunOnVirtualThread ... ?

It depends on the order in which interceptors are applied.

Or this has changed now by default, and if someone is depending on this impl-details, it will break the current interceptors?

I don't think it is a big deal as interceptors are still applied by priority.