-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Arc - Decide whether req. context is active based on validity of its ContextState #38107
Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this fixes the first reproducer, but does not fix the second one (the one with gRPC security event observer, but I don't think it's related to events only).
I can see the request context state invalidated same amount of times as activated when arriving to io.quarkus.grpc.runtime.supports.context.GrpcRequestContextGrpcInterceptor#interceptCall
I can see it active. You have better chance to figure why it works this way, could you look please? Separately, this change is good in my eyes, but @mkouba should decide that.
Sure, I'll take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the fix is correct. The original implementation of VertxCurrentContext.remove()
did not reflect the fact that RequestContextState
can be invalidated before the HTTP request processing ends.
CC @franz1981 as this fix means one more |
@@ -112,7 +112,8 @@ public <T> T get(Contextual<T> contextual) { | |||
|
|||
@Override | |||
public boolean isActive() { | |||
return currentContext.get() != null; | |||
RequestContextState requestContextState = currentContext.get(); | |||
return requestContextState == null ? false : requestContextState.isValid(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fine, the only downside is the dependent load, but having a volatile load is pretty cheap on most architecture, and regardless... there is not much to do here, given that we requires correctness first!
I've added a test for this change as well and I've reached out to Michal over Zulip to discuss this further. |
✔️ 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. |
- this is a follow-up of quarkusio#38107
- this is a follow-up of quarkusio#38107
- this is a follow-up of quarkusio#38107 (cherry picked from commit 7db82da)
Fixes #37741
@michalvavrik Can you give this a spin please? I did test it with your first reproducer (the
code-with-quarkus
with added observer) but not much else yet.I am still trying to understand why we never clear the context state from duplicated context but I didn't get any closer to an explanation yet. It could just be an optimization 🤷
I'll try to some simple test as well but I first wanted to see what CI thinks about it as I only ran tests from few modules locally.