Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
Rollouts skipped this pull request: Documentation-only changes in application repos (modified develop-docs MDX files that are not getsentry/sentry-docs or getsentry/sentry-changelog). Mention |
| envelope.headers.trace = current_segment_span.dynamic_sampling_context | ||
| ``` | ||
|
|
||
| <Expandable title="Previous behavior (spec versions 1.0.0 to 1.3.0)"> |
There was a problem hiding this comment.
since the old version is still "valid" for SDKs without span streaming, the 1.3 algorithm stays as an expandable section
Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
Dav1dde
left a comment
There was a problem hiding this comment.
LGTM though this is a lot of SDK specifics I am not familiar with, when and how the DSC is treated within SDKs. The most important part is that there is always a trace header on the envelope which "describes" all contained standalone spans.
|
|
||
| If an SDK receives a `sentry-trace` header but no DSC (no `baggage` header with `sentry-` values), continues the trace, and starts a segment span: | ||
|
|
||
| - The SDK **MUST NOT** freeze an empty DSC for the continued trace. |
There was a problem hiding this comment.
Just commentary: An empty DSC was also never a valid DSC. It requires project key and trace id.
There was a problem hiding this comment.
"Empty" translated to no trace header being sent and DSC no DSC values being propagated via baggage. I agree that this isn't clearly worded. Will reword a bit.
DESCRIBE YOUR PR
Adjusts an edge case in the DSC spec and the unified propagation mechanism which was incompatible with span streaming.
Scenario: SDK receives an incoming trace with a
sentry-traceheader but no DSC via thebaggageheader (e.g. because the upstream SDK is not compatible with DSC)Previously: SDKs should freeze an empty DSC to the server span. This resulted in SDKs adding no
traceenvelope header to their envelopes, and neither propagating the DSC viabaggageto downstream services.Changed: SDKs should materialize a DSC from their own data (i.e. from the segment span as well as information on their client), freeze it to their segment span. This results in a
traceenvelope header on spans and the DSC being propagated viabaggageto downstream SDKs.SDKs are going to be required to implement the new version (1.4) of the spec when implementing span streaming.
Why this change?
Span v2 envelopes require a
traceenvelope header to be set by SDKs. For transactions, Relay would infer a DSC from an incomingtrace-less transaction envelope. Relay can no longer do this reliably for streamed v2 spans since there's no guarantee that a segment span is in the envelope. Therefore SDKs need to take over this part.In practise, SDKs have sadly diverged quite a bit from the previously specified behavior for this edge case, with some of them constructing and sending the DSC already for a baggage-less incoming traces. Some send invalid DSC (missing required values) and some actually stick to the 1.3 spec version. With SDKs being required to implement 1.4 when working on span streaming, we can hopefully align them again.
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
Select exactly one option. For deadlines, replace
YYYY-MM-DDwith the due date. You can update this information later by editing the PR description.SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes: