Running Blocking RestEasy Reactive @PreMatching filters

[bcluap]

Hi,

I've seen a number of questions and bug/feature requests mentioning people trying to do blocking calls in a prematching filter. I'm hitting this issue as I want to do some path rewriting that needs to do blocking to decide what to replace tokens on the path with. Here is my actual usecase:
We have a rest resource on a path like /users/{userId} e.g. GET /users/123
We have a lot of sub resources such as GET /users/123/addresses and GET /users/123/identities etc

We now have a customer saying they do not want to use our systems unique user ID on the path and want to use their own ID. We do happen to have their ID as well. E.g. in our user table we have userId and externalUserId both as unique keys. So as an example, lets say user id 123 has an external id of ABC. They want to call GET /users/EID-ABC (we agreed they prefix with EID- so we know its an external Id.

I proceeded to add some path augmentation into a @PreMatching filter that would see EID-ABC and do a call to our user microservice over HTTP to get the user with external Id ABC and see its internalId is 123 and then set the URI to /users/123 so from then on its as though the client called /users/123.

This works great in theory and avoids us having to create a whole lot of new rest endpoints to cater for a different resource identifier on the path. In practice though I cannot for the life of me get the Prematching filter to run on a virtual or platform thread. It runs on the event loop and blocks it. Our normal filters after PreMatching run on Virtual Threads as our resources are annotated as such, and if I add @RunOnVirtualThread or @Blocking or even both on the PreMatching filter, it still runs on the eventloop.

Is this a bug? SHould I be able to do prematching off the event loop?

++ @geoand I know you are the expert here

Thanks so much

[bcluap]

I've managed to do a workaround where the prematching augmentation filter suspends the requestcontext and does the HTTP calls reactively and then when the results come back the requestcontext is updated with the new URI and then resumed

[geoand]

You mean using ResteasyReactiveContainerRequestFilter?

[bcluap]

Calling this to suspend :

quarkus/independent-projects/resteasy-reactive/server/runtime/src/main/java/org/jboss/resteasy/reactive/server/jaxrs/ContainerRequestContextImpl.java

Line 213 in 22bed79

public void suspend() {

And then the line 218 to resume. So I have a @PreMatching filter. It suspends the request and does whatever calls it wants to do reactively. When the result comes back reactively, it sets the updated URI on the request and then calls resume().

[geoand]

Gotcha, thanks. I think using @ServerRequestFilter should also work if you return Uni<Void>