Repository navigation
fix(tracing): Propagate the span of the hub passed to the Guzzle middleware - #2289
Conversation
|
Thanks for the PR! I think it would be easier to update the top level functions to take a function getTraceparent(HubInterface $hub = null): string
{
$hub = $hub ?? SentrySdk::getCurrentHub();
// the rest
}same for edit: I noticed we call |
Pass the Guzzle middleware hub to both functions instead of reading the span directly, and use the given hub consistently inside them.
|
@Litarnus Thanks, that is simpler. The PR now takes that approach:
Both tests fail without the source change and pass with it. The unit suite passes (2007 tests). CHANGELOG.md is not touched, since it is updated during releases. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit c8a01c8. Configure here.
|
The CI is unrelated to your changes, the recent PHP vulnerability seem to have changed behaviour around OOM. I will fix it in a different PR and merge it here |
When the given hub has no span, getBaggage() builds the header from the scope's propagation context, which read the current hub's options. Pass the hub to PropagationContext::toBaggage() so the fallback uses it too.
Litarnus
left a comment
There was a problem hiding this comment.
Very nice, thank you for fixing this

fix(tracing): Propagate the span of the hub passed to the Guzzle middleware
Description
GuzzleTracingMiddleware::trace()accepts a hub and starts thehttp.clientspan on it, but it built thesentry-traceandbaggageheaders withgetTraceparent()andgetBaggage(), which always readSentrySdk::getCurrentHub(). When the given hub is not the current hub, the outgoing request carried the trace of another hub, and the downstream service continued a trace that does not contain thehttp.clientspan.getTraceparent()andgetBaggage()now accept an optional hub and fall back to the current hub. Both functions use that hub consistently, and the middleware passes its hub to them.The existing tests set the given hub as the current hub, so they did not cover this case. The new tests use two different hubs.
Issues
Reminders
feat:,fix:,ref:,meta:)