misc: Add support for bridge spans#5895
Merged
Merged
Conversation
These will use `bridge_trace_id` to map an exising client transaction/span to this one so they'll be displayed as a single one in Sentry. This is done through the `sentry.trace` field, which will be used by `sentry-tracing` to differentiate these kinds of special spans. The special fields need to be added on the Span creation, that's why we do it in the constructor instead of just using `span.record(...)` later.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5895 +/- ##
==========================================
- Coverage 88.65% 88.64% -0.01%
==========================================
Files 362 362
Lines 103146 103146
Branches 103146 103146
==========================================
- Hits 91440 91437 -3
- Misses 7458 7460 +2
- Partials 4248 4249 +1 ☔ View full report in Codecov by Sentry. |
CodSpeed Performance ReportMerging #5895 will not alter performanceComparing Summary
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bridge spans will use
bridge_trace_idto map an existing client transactions/spans to Rust ones so they'll be displayed as a single one in Sentry.This is done through the
sentry.tracefield, which will be used bysentry-tracingto differentiate these kinds of special spans (see docs).The special fields need to be added on the Span creation, that's why we do it in the constructor instead of just using
span.record(...)later.Also bumps Sentry SDK to the latest version.
Note this doesn't seem to work 100% of the time:
It might be some bug in the Sentry SDK.Ot a race condition that happens when the SDK spans are received before the client ones.Or maybe our Sentry instance has a bug since it's a bit out of date.Until all the code that runs using that span has finished (including spawned long running tasks) Sentry doesn't consider the span as ready to upload. We can't force sentry to send the span ahead of time (at least, there is no way that I know given how
sentry-tracingworks), so in those cases the spans just won't be uploaded.The result is sometimes you get flawless results, everything is uploaded and works smoothly, and other times no matter how many times you try, the SDK spans won't be uploaded/attached. However, the time metrics for the spans won't change, so not having the SDK spans, while not ideal, it's not mandatory to have consistent metrics.
Signed-off-by: