-
-
Notifications
You must be signed in to change notification settings - Fork 166
fix(actix): process request in other middleware using correct Hub #758
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
sentry-actix/src/lib.rs
Outdated
//! .get::<Arc<Hub>>() | ||
//! .unwrap_or(&Hub::current()) // should never happen | ||
//! .clone(); |
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.
//! .get::<Arc<Hub>>() | |
//! .unwrap_or(&Hub::current()) // should never happen | |
//! .clone(); | |
//! .get::<Arc<Hub>>() | |
//! .cloned() | |
//! .unwrap_or(Hub::current()); // should never happen |
If this is just the same as Hub::current()
, I wonder what purpose this serves?
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.
Are you referring to the clone
or what?
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've updated it to just use unwrap
, if we apply our middleware first it's guaranteed to be there anyways.
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 mean what is the purpose of storing this in the request extensions at all, if its the same value as is available from Hub::current()
?
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.
Yeah that was misleading, it was just for the sake of not unwrapping.
The whole reason this PR exists is because Hub::current()
and the hub stored in the extension are different.
To explain better why we need to pass the per-request hub in the extensions:
when we do svc.call
here
sentry-rust/sentry-actix/src/lib.rs
Line 403 in a6f1db2
let fut = svc.call(req).bind_hub(hub.clone()); |
it first processes the request through all middleware, and then returns us a future that refers only to the response half of the processing (i.e. handler execution + middleware processing of the response).
So, during request processing, we need to use extensions to pass the correct hub to the subsequent middleware.
Let me know if you see a better solution that I might have missed.
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.
oh, so the svc.call
part does not run in the current hub?
well in that case, we have to activate the hub within the function that calls svc.call
, as well as binding it to the future like we do right now.
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.
Oh I see. Fixed it now:
sentry-rust/sentry-actix/src/lib.rs
Line 341 in ae8c91d
let fut = Hub::run(hub.clone(), || svc.call(req)).bind_hub(hub.clone()); |
Thanks, that's much better! Obviously it doesn't require using the extensions.
Extensions are a feature of Actix-web to pass request-local data.
With this change, we pass the Hub that we create with each Actix request in the extensions, so that other middleware can access it and use it to capture events within the correct hub.
Closes #624