-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(browser): Add support for propagateTraceparent
SDK option
#17509
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
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
size-limit report 📦
|
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
propagateTraceparent
SDK option (削除ここまで)propagateTraceparent
SDK option (追記ここまで)
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
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.
LGTM!
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.
👀 we don't have this logic in sentry-java
, but I'll add it too. There's an edge case: if the request has a sentry-trace
header, but lacks baggage/traceparent header, we won't add baggage/traceparent here. But I think that's fine, otherwise you could end up in situations where the header values don't match up.
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.
if the request has a
sentry-trace
header, but lacks baggage/traceparent header, we won't add baggage/traceparent here
yes correct and I agree that this is fine. sentry-trace
is still the minimum required header for our trace propagation to work according to our DSC dev spec. (Server) SDKs have to handle incoming requests where only sentry-trace
is sent. This was primarily required for backwards compatibility but I think this case is another valid (though very edge-casey) reason to do so. So I think this should be safe.
My rationale here is: If users really attach their custom tracing headers (already unlikely but it happened), it's on them to do it properly. We export functions like Sentry.getTraceData()
to make this as easy as possible. Everything we do in the SDK would be a "best guess" effort and likely leads to unexpected results.
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.
lgtm!
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.
🥲
Uh oh!
There was an error while loading. Please reload this page.
This PR adds support for a new browser SDK init option,
propagateTraceparent
, as spec'd out in our develop docsIf users opt into
propagateTraceparent
, browser SDKs will attach a W3C complianttraceparent
header to outgoing fetch and XHR requests, in addition tosentry-trace
andbaggage
headers.A couple of implementation remarks:
@sentry/core
.instrumentFetchRequest
function in core because it already took an optional param. Nothing major though in terms of breakage but this is a publicly exported function, so we can't just simply break the signature.generateSentryTraceHeader
returns a random uuid if we're in TwP mode. If we were to generate a traceparent header from the same data set, we'd also have to create a random uuid, meaning we'd end up with sentry-trace and traceparent headers on the same request with different (non-existing) parentSpanIds. If we just take the finished header, and morph it into the other header we can avoid this entirely.parentSpanId
stays consistent during trace in TwP mode #17526 will improve this by properly generating atraceparent
header. Which requires some additional TwP trace propagation changes, so I decided to keep this separate.closes #17482