Skip to content

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

Merged
merged 6 commits into from
Mar 26, 2025

Conversation

lcian
Copy link
Member

@lcian lcian commented Mar 25, 2025

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

Comment on lines 104 to 106
//! .get::<Arc<Hub>>()
//! .unwrap_or(&Hub::current()) // should never happen
//! .clone();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
//! .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?

Copy link
Member Author

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?

Copy link
Member Author

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.

Copy link
Member

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()?

Copy link
Member Author

@lcian lcian Mar 25, 2025

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

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.

Copy link
Member

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.

Copy link
Member Author

@lcian lcian Mar 26, 2025

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:

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.

@lcian lcian requested a review from Swatinem March 25, 2025 15:31
@lcian lcian changed the title feat(actix): pass request Hub in request extensions fix(actix): use correct Hub when processing request through middleware Mar 26, 2025
@lcian lcian changed the title fix(actix): use correct Hub when processing request through middleware fix(actix): use correct Hub when processing request in other middleware Mar 26, 2025
@lcian lcian changed the title fix(actix): use correct Hub when processing request in other middleware fix(actix): process request in other middleware using correct Hub Mar 26, 2025
@lcian lcian merged commit 44fa0cf into master Mar 26, 2025
14 checks passed
@lcian lcian deleted the lcian/feat/actix-pass-hub branch March 26, 2025 12:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unable to add a breadcrumb from actix-web middleware
2 participants