Migrating to 3.13.0 results in failure on quarkus reactive routes

[gautamlihala]

Describe the bug

We have some rest endpoints configured to return Uni. Until 3.12.3 there was no issue. On migrating to 3.13.0 we have started observing null pointer exceptions. All the non-reactive routes work.

Expected behavior

The application should work as expected.

Actual behavior

java.lang.NullPointerException: Cannot read field "identityAssociation" because "io.quarkus.resteasy.reactive.server.runtime.security.EagerSecurityContext.instance" is null
at io.quarkus.resteasy.reactive.server.runtime.security.SecurityContextOverrideHandler.updateIdentity(SecurityContextOverrideHandler.java:50)
at io.quarkus.resteasy.reactive.server.runtime.security.SecurityContextOverrideHandler.handle(SecurityContextOverrideHandler.java:45)
at io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:119)
at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:147)
at org.jboss.resteasy.reactive.server.handlers.RestInitialHandler.beginProcessing(RestInitialHandler.java:48)
at org.jboss.resteasy.reactive.server.vertx.ResteasyReactiveVertxHandler.handle(ResteasyReactiveVertxHandler.java:23)
at org.jboss.resteasy.reactive.server.vertx.ResteasyReactiveVertxHandler.handle(ResteasyReactiveVertxHandler.java:10)
at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1285)
at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:177)
at io.vertx.ext.web.impl.RoutingContextWrapper.next(RoutingContextWrapper.java:200)
at io.quarkus.vertx.http.runtime.VertxHttpRecorder$8.handle(VertxHttpRecorder.java:610)
at io.quarkus.vertx.http.runtime.VertxHttpRecorder$8.handle(VertxHttpRecorder.java:604)
at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1285)
at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:177)
at io.vertx.ext.web.impl.RoutingContextWrapper.next(RoutingContextWrapper.java:200)
at io.quarkus.vertx.http.runtime.options.HttpServerCommonHandlers$1.handle(HttpServerCommonHandlers.java:62)
at io.quarkus.vertx.http.runtime.options.HttpServerCommonHandlers$1.handle(HttpServerCommonHandlers.java:40)
at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1285)
at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:177)
at io.vertx.ext.web.impl.RoutingContextWrapper.next(RoutingContextWrapper.java:200)
at io.quarkus.resteasy.reactive.server.runtime.ResteasyReactiveRecorder$13.handle(ResteasyReactiveRecorder.java:358)
at io.quarkus.resteasy.reactive.server.runtime.ResteasyReactiveRecorder$13.handle(ResteasyReactiveRecorder.java:347)
at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1285)
at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:177)
at io.vertx.ext.web.impl.RoutingContextWrapper.next(RoutingContextWrapper.java:200)
at io.vertx.ext.web.impl.RouterImpl.handleContext(RouterImpl.java:250)
at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1285)
at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:177)
at io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:140)
at io.quarkus.vertx.http.runtime.devmode.VertxHttpHotReplacementSetup$5.handle(VertxHttpHotReplacementSetup.java:204)
at io.quarkus.vertx.http.runtime.devmode.VertxHttpHotReplacementSetup$5.handle(VertxHttpHotReplacementSetup.java:192)
at io.vertx.core.impl.future.FutureImpl$4.onSuccess(FutureImpl.java:176)
at io.vertx.core.impl.future.FutureBase.lambda$emitSuccess$0(FutureBase.java:60)
at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:994)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:1583)

How to Reproduce?

No response

Output of uname -a or ver

Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000 arm64

Output of java -version

openjdk version "17.0.10" 2024-01-16 LTS OpenJDK Runtime Environment Zulu17.48+15-CA (build 17.0.10+7-LTS) OpenJDK 64-Bit Server VM Zulu17.48+15-CA (build 17.0.10+7-LTS, mixed mode, sharing)

Quarkus version or git rev

3.13.0

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) Maven home: .m2/wrapper/dists/apache-maven-3.9.9-bin/33b4b2b4/apache-maven-3.9.9 Java version: 17.0.10, vendor: Azul Systems, Inc., runtime: /Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home Default locale: en_NL, platform encoding: UTF-8 OS name: "mac os x", version: "14.6.1", arch: "aarch64", family: "mac"

Additional information

We use custom auth flow using SecurityOverridefilter via the ServerRequestFilter annotation

@ServerRequestFilter(preMatching = true, priority = 2, nonBlocking = true)
public Uni<Response> performAuth(ContainerRequestContext requestContext, UriInfo uriInfo, HttpHeaders httpHeaders) {
    return authenticationService.delegate(requestContext, uriInfo, httpHeaders);
  }

And the security context is set in this ContainerRequestContext after successful auth.

[quarkus-bot]

/cc @FroMage (rest), @stuartwdouglas (rest)

[geoand]

cc @michalvavrik

[michalvavrik]

I'd like to check, but there is not all that much information. You see, this io.quarkus.resteasy.reactive.server.runtime.security.EagerSecurityContext.instance can only be null if app startup hasn't finished, but then, the HTTP server used to only listen when all the sync startup events has finished. Or maybe, you could observe it, on app shutdown? This could be handled.

@gautamlihala I cannot spend time guessing how to reproduce it as there is too many of variants. could you maybe provide reproducer? If that is not possible, we need more information, at which point it does exactly happen etc. More info better.

Expected behavior: The application should work as expected.

Problem is that you don't describe how application does not work in detail. There is no context to the NPE. Please also try different Quarkus version then 3.13, but the best thing would be reproducer.

Thank you for reporting

[michalvavrik]

ha, I think I might have guessed it! Any chance you don't use Quarkus Security (you don't have Quarkus Security present at all?). I think I have never thought about this before, I'll try to create reproducer myself, but still, if you can provide one, that would be for the best because I cannot guarantee that my guess matches your scenario.

[michalvavrik]

And the security context is set in this ContainerRequestContext after successful auth.

Ah, alright, so you set the security context yourself. I'd still like to have your confirmation you don't have Quarkus Security present at all, just implement security yourself, but I'll provide fix anyway. Thanks again

[gautamlihala]

Hi @michalvavrik,

Thanks for replying on this. Indeed I do not use quarkus-security as a dependency directly but I also saw it being injected transitively so did not think it to be a culprit. But I will give it a try.

Initially I was lost as to what additional information to provide.

I will check if I can provide a reproducer and which piece of information can be relevant to this.

[michalvavrik]

@gautamlihala no worry, that confirmation regarding quarkus-security was just enough. #43425 should fix it. indeed, I did not consider your scenario when making changes.

[michalvavrik]

I also saw it being injected transitively so did not think it to be a culprit

IMO you might have confuse it with SPI or Quarkus Security (which is same named API :-)), but if you are convinced you really have Quarkus Security present, please provide reproducer. I don't know how could NPE happen in that case, but who knows.

[michalvavrik]

by Quarkus Security API I meant https://github.com/quarkusio/quarkus-security

[gautamlihala]

I will check, thanks for this so far.

[gautamlihala]

@michalvavrik

Checked, I have quarkus-smallrye-openapi as a depedency which was bringing in quarkus-security as a transitive dependency. I explicitly added quarkus-security (2.1.0) as a direct dependency but the issue persisted.

[michalvavrik]

Checked, I have quarkus-smallrye-openapi as a depedency which was bringing in quarkus-security as a transitive dependency.

no, it doesn't

I explicitly added quarkus-security (2.1.0) as a direct dependency but the issue persisted.

you are adding io.quarkus.security:quarkus-security while you need to add io.quakrus:quarkus-security

[gautamlihala]

@michalvavrik,

I misunderstood your previous message. Indeed adding io.quarkus:quarkus-security solved the issue. Thanks for the all the help on this and the quick fix that you have provided. Will wait for the next release and meanwhile have this gav in so that we can progress.

[michalvavrik]

@michalvavrik,

I misunderstood your previous message. Indeed adding io.quarkus:quarkus-security solved the issue. Thanks for the all the help on this and the quick fix that you have provided. Will wait for the next release and meanwhile have this gav in so that we can progress.

perfect, thanks for confirmation and reporting this issue