quarkus: Context propagation is not working for WebSocket.

Describe the bug

The context propagation is not working for WebSocket. Please referred this post here. https://github.com/quarkusio/quarkus/discussions/30905#discussioncomment-4898246 @sberyozkin suggest that create a simple reproduce project to validate this. But I have no idea what bean can be injected to validate. Or maybe anyone other reproduce this. From the thread name we can find the difference.

Expected behavior

The context propagation should work for WebSocket. The security identity should be the same. Should not lost the authentication. Here’s a snapshot that context propagation is working

Actual behavior

The context propagation is not working for WebSocket. The security identity become anonymous. Here’s a snapshot that context propagation is not working.

How to Reproduce?

Just use the Actual behaviour code to reproduce. But it may need some settings with security.

I have no idea how to reproduce this without security.

Output of `uname -a` or `ver`

Microsoft Windows [版本 10.0.19045.2486]

Output of `java -version`

openjdk 11.0.12 2021-07-20 OpenJDK Runtime Environment Microsoft-25199 (build 11.0.12+7) OpenJDK 64-Bit Server VM Microsoft-25199 (build 11.0.12+7, mixed mode)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.0.0.Alpha3

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

------------------------------------------------------------ Gradle 7.5.1 ------------------------------------------------------------ Build time: 2022-08-05 21:17:56 UTC Revision: d1daa0cbf1a0103000b71484e1dbfe096e095918 Kotlin: 1.6.21 Groovy: 3.0.10 Ant: Apache Ant™ version 1.10.11 compiled on July 10 2021 JVM: 11.0.15 (GraalVM Community 11.0.15+10-jvmci-22.1-b06) OS: Windows 10 10.0 amd64

Additional information

No response

About this issue

Original URL
State: closed
Created a year ago
Comments: 17 (8 by maintainers)

Most upvoted comments

Thank you for your clarification. It does help. I know how refactor the code for my need now.

SetoKaiba on Apr 3, 2023

@SetoKaiba even without the example properly working, I think I can see why the CDI context isn’t propagating for the @OnOpen method and I suppose the REST method will have the exact same problem.

The setup you are doing with ManagedExecutor is technically correct and you will have req. context active inside the task you submit (which you are correctly testing). However, it will be a different req. context - you can see this if you ask Arc for the underlying context state and then log it like this:

 InjectableContext.ContextState state = Arc.container().requestContext().getState();
 logger.info(state + " is valid: " + state.isValid());

Do the same from inside the ManagedExecutor task you are submitting and you can see the difference.

The problem is that you are trying to use CDI context after it has already ended (and been invalidated) on the original thread. That is not permitted because otherwise you could extend request context life indefinitely and CDI would not know when to terminate such context as threads could just endlessly pass it around. Therefore, during context propagation, Arc checks the ContextState object and if it is invalid, it will instead create a fresh req. context.

Here is a Gist with two variations of your code that you can try and see what I mean - https://gist.github.com/manovotn/2fe271caab8f0f9e74417eebb162197a

manovotn on Apr 3, 2023