sentry-rust
sentry-rust copied to clipboard
Breadcrumbs are Unrelated to Issues
Problem Statement
The problem seems similar to an older github issue, where the solution relied on sentry-actix for setting up a hub per request for ensuring that requests do not share breadcrumbs.
Continuation of issue.
Solution Brainstorm
I am noticing breadcrumbs hours apart show up in my issues, some seem unrelated, and want to customize how they get grouped. I am looking for an alternative to using sentry-actix middleware, ideally a solution that does not require a provider.
Thanks @cobyeastwood183, I'll look into this. In the meantime, could we get a small repro sample from the user? That would help.
@lcian, thank you! More details are available in this ticket, https://sentry.zendesk.com/agent/tickets/154533. I will follow up for a repro.
Thanks @cobyeastwood183 ! I've requested zendesk access because I don't have it.
Based on what I see in the ticket, the user is using the middleware in the tracing-actix-web crate to start a tracing root span on every HTTP request.
Then they're using our sentry-tracing layer to convert tracing spans into Sentry spans.
In order to have correct breadcrumbs without using sentry-actix, the user would need to manually manage hubs.
This means they would have to extend the tracing-actix-web middleware to wrap the request-response cycle in something like:
let hub = sentry::Hub::new_from_top(sentry::Hub::current());
sentry::Hub::run(hub, || /* handle the request */);
If any futures are used inside the run call, they also need to bind the hub to the future to ensure the correct hub is used when polling it, as follows:
let res = future.bind_hub(sentry::Hub::current()).await;
This basically replicates the hub management logic that is inside sentry-actix.
I haven't looked into the code for tracing-actix-web too much but it's possible that to accomplish this they would need to fork it.
@lcian thank you! Will forward this over.
@cobyeastwood183 Hey, actually they can just use the sentry-actix middleware but set capture_server_errors to false (it's true by default).
This way, the middleware will only manage the hub and fork it upon each request, which is what we're trying to achieve here.
Please forward this over too.