Vertx RouteFilter not propagating request context to a resteasy-reactive resource

[HerrDerb]

Describe the bug

When having a @RouteFilter setting information on a @RequestScoped bean, the bean is not being propagated correctly and the information is lost as a new request scope is beeing openend.

Expected behavior

The request scope of an @RouteFilter should be propagated to my jakarta.ws rest controller.

Actual behavior

A new request scope is beeing opened between my @RouteFilter and the invocation of my rest controller.

2023-07-12 10:24:06,341 INFO  [io.quarkus] (main) code-with-quarkus 1.0.0-SNAPSHOT on JVM (powered by Quarkus 3.1.2.Final) started in 2.462s. Listening on: http://localhost:8081
2023-07-12 10:24:06,367 INFO  [io.quarkus] (main) Profile test activated. 
2023-07-12 10:24:06,367 INFO  [io.quarkus] (main) Installed features: [cdi, jacoco, reactive-routes, resteasy-reactive, smallrye-context-propagation, vertx]
2023-07-12 10:24:07,578 WARN  [org.acm.iss.RequestScopedBean] (vert.x-eventloop-thread-0) ## New RequestScopedBean created
2023-07-12 10:24:07,579 WARN  [org.acm.iss.VertxRoutFilter] (vert.x-eventloop-thread-0) ## value from field 'info' of request scoped bean: testParamValue 
2023-07-12 10:24:07,584 WARN  [org.acm.iss.ExampleRestController] (executor-thread-1) ## Handeling getRequetScopedInfo
2023-07-12 10:24:07,584 WARN  [org.acm.iss.RequestScopedBean] (executor-thread-1) ## New RequestScopedBean created
2023-07-12 10:24:07,584 WARN  [org.acm.iss.ExampleRestController] (executor-thread-1) ## value from field 'info' of request scoped bean: null
2023-07-12 10:24:07,587 WARN  [org.acm.iss.RequestScopedBean] (executor-thread-1) ## RequestScopedBean destroyed
2023-07-12 10:24:07,587 WARN  [org.acm.iss.RequestScopedBean] (executor-thread-1) ## RequestScopedBean destroyed
2023-07-12 10:24:07,694 INFO  [io.quarkus] (main) code-with-quarkus stopped in 0.027s

How to Reproduce?

https://github.com/HerrDerb/quarkus-issue/tree/vertx-requestscope-issue

[HerrDerb]

Similar to #13073

[geoand]

cc @mkouba

[mkouba]

It seems that ArcThreadSetupAction does not check if an existing context exists but always activates a new one.

I can confirm that we only have a test for reactive routes.

[geoand]

It seems that ArcThreadSetupAction does not check if an existing context exists but always activates a new one

Should we be checking if one already exists?

[mkouba]

It seems that ArcThreadSetupAction does not check if an existing context exists but always activates a new one

Should we be checking if one already exists?

I think so, yes. The whole ArcThreadSetupAction should be a no-op if the context is already active. Hope that does not break anything ;-).

[geoand]

I am sure it will :)

But I'll check it out tomorrow.

[geoand]

Let's see what CI will say for #34724

[HerrDerb]

So in the meantime I'll just leave with two mutual exclusive request filters. What definitly feels odd is, that I need to include the reactive-routes dependency to filter vertx requests which are already enabled with resteasy reactive

[mkouba]

What definitly feels odd is, that I need to include the reactive-routes dependency to filter vertx requests which are already enabled with resteasy reactive

In fact, you only need the reactive-routes for the declarative approach.

You can use the io.quarkus.vertx.http.runtime.filters.Filters as described in the javadoc: https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/filters/Filters.java#L14-L24.

Or even observe and configure the io.vertx.ext.web.Router as described in this example: https://quarkus.io/guides/vertx-reference#bidirectional-communication-with-browsers-by-using-sockjs.

[HerrDerb]

@mkouba interestingly, the request scope seems only managed/ propagated properly when using the declarative approach with quarkus-reactive-routes. When registering the filter over @Observes, as you suggested to avoid the dependency, the request scope is not propagated correctly, more specificaly a new request scope is created after the filter on the executor thread.

[mkouba]

@mkouba interestingly, the request scope seems only managed/ propagated properly when using the declarative approach with quarkus-reactive-routes. When registering the filter over @Observes, as you suggested to avoid the dependency, the request scope is not propagated correctly, more specificaly a new request scope is created after the filter on the executor thread.

Well, a declarative filter goes through RouteHandler#handle() which among other things only activates the request context if not active. A filter registered through an observer is used as-is.

[Eng-Fouad]

Any updates regarding this issue? Thanks.

[geoand]

Closing as this was implemented in #40408