chore(core): Implement disabled tracing semantics - #1286
Open
szokeasaurusrex wants to merge 4 commits into
Open
Conversation
szokeasaurusrex
changed the title
szokeasaurusrex
force-pushed
the
szokeasaurusrex/fix/fully-distinguish-disabled-tracing
branch
from
August 10, 2026 15:32
3287209 to
0392622
Compare
szokeasaurusrex
marked this pull request as ready for review
August 10, 2026 15:33
szokeasaurusrex
force-pushed
the
szokeasaurusrex/fix/fully-distinguish-disabled-tracing
branch
from
August 10, 2026 15:49
0392622 to
3b583f6
Compare
szokeasaurusrex
marked this pull request as draft
August 11, 2026 11:18
szokeasaurusrex
force-pushed
the
szokeasaurusrex/fix/fully-distinguish-disabled-tracing
branch
from
August 11, 2026 11:26
3b583f6 to
08ed195
Compare
szokeasaurusrex
changed the base branch from
master
to
szokeasaurusrex/feat/new-dsc-methods
August 11, 2026 11:26
szokeasaurusrex
force-pushed
the
szokeasaurusrex/fix/fully-distinguish-disabled-tracing
branch
from
August 11, 2026 11:43
08ed195 to
9ed110b
Compare
szokeasaurusrex
changed the title
szokeasaurusrex
force-pushed
the
szokeasaurusrex/fix/fully-distinguish-disabled-tracing
branch
from
August 12, 2026 10:11
9ed110b to
0c73e73
Compare
szokeasaurusrex
changed the base branch from
szokeasaurusrex/feat/new-dsc-methods
to
szokeasaurusrex/chore/deprecate-is-sampled
August 12, 2026 10:11
szokeasaurusrex
added a commit
that referenced
this pull request
Aug 12, 2026
Deprecate the `is_sampled` methods on `Transaction`, `Span`, and `TransactionOrSpan` because these methods no longer faithfully represent the sampling state of these objects now that the SDK can properly represent the tracing-disabled state. This will be even more true after the follow up PR #1286 is merged; that's because that PR changes these struct's internal `sampled` representation to accurately represent the disabled-tracing states. This PR also removes `is_sampled` assertions from the trace continuation tests. These assertions are not needed because the tests' purpose is to check trace continuation, not sampling decision propagation. These `is_sampled` checks should probably never have been added there. We are not adding a replacement for `is_sampled` because a review of code in the `getsentry` org and public GitHub repos did not reveal any usecases of `is_sampled` that could not be replaced with another reasonable existing alternative, e.g. the functions that return the trace propagation headers. In `getsentry`, no usages of these methods could be found outside the SDK itself.
szokeasaurusrex
force-pushed
the
szokeasaurusrex/fix/fully-distinguish-disabled-tracing
branch
from
August 12, 2026 20:30
152813a to
ca9bbe7
Compare
szokeasaurusrex
commented
Aug 12, 2026
Comment on lines
+995
to
+996
| .with_sample_rate(sample_rate) | ||
| .with_sampled(true); |
Member
Author
There was a problem hiding this comment.
If we are sending the transaction, that means that the transaction is sampled.
Member
Author
|
@giortzisg in case you took at this PR earlier, just a heads up that I have fundamentally changed it. The previous implementation conflated sampling decision and tracing enabled/disabled by assuming that a deferred sampling decision is equivalent to tracing being disabled. This is true when we are the SDK starting the trace, but if we are continuing an incoming trace, we need to be able to correctly represent that tracing is disabled, but that there is still a sampling decision that needs to be propagated outwards. |
szokeasaurusrex
marked this pull request as ready for review
August 12, 2026 21:03
giortzisg
approved these changes
Aug 13, 2026
PR #1227 enabled us to represent disabled tracing differently from a 0.0 sample rate when the SDK is initialized but left the behavior for the two cases largely the same. This change fundemantally alters the semantics around how disabled tracing is handled. Spans/Transactions now keep track of a so-called `TracingState` which keeps track of both whether tracing is enabled and what the sampling decision is. When tracing is enabled, there will always be a sampling decision (including a corresponding sample rate); when tracing is disabled, a sampling decision may be available if the trace was continued from an incoming trace with a sampling decision. Traces started in the SDK when tracing is disabled never have a sampling decision. We then separate the concepts of sampling decision and whether to capture traces. The sampling decision now can correctly represent the case where the decision has been deferred. Span/Transaction tracing headers will always include this sampling decision, regardless of whetehr the SDK is capturing the corresponding the Span/Transaction. For whether to capture traces, we now use a `FinishAction` with three possibilities: `Send` and `Discard` are both used when tracing is enabled and are used for sampled and unsampled traces, respectively, while `Ignore` is used for all traces when tracing is disabled. Both `Discard` and `Ignore` result in spans/transactions not being sent to Sentry, but only `Discard` sends a client report. Resolves [#1289](#1289) Resolves [RUST-273](https://linear.app/getsentry/issue/RUST-273) Resolves [#1282](#1282) Resolves [RUST-272](https://linear.app/getsentry/issue/RUST-272)
szokeasaurusrex
force-pushed
the
szokeasaurusrex/fix/fully-distinguish-disabled-tracing
branch
from
August 26, 2026 19:35
277ccdd to
2e1a090
Compare
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.
PR #1227 enabled us to represent disabled tracing differently from a 0.0 sample rate when the SDK is initialized but left the behavior for the two cases largely the same.
This change fundamentally alters the semantics around how disabled tracing is handled.
Spans/Transactions now keep track of a so-called
TracingStatewhich keeps track of both whether tracing is enabled and what the sampling decision is. When tracing is enabled, there will always be a sampling decision (including a corresponding sample rate); when tracing is disabled, a sampling decision may be available if the trace was continued from an incoming trace with a sampling decision. Traces started in the SDK when tracing is disabled never have a sampling decision.We then separate the concepts of sampling decision and whether to capture traces. The sampling decision now can correctly represent the case where the decision has been deferred. Span/Transaction tracing headers will always include this sampling decision, regardless of whetehr the SDK is capturing the corresponding the Span/Transaction. For whether to capture traces, we now use a
FinishActionwith three possibilities:SendandDiscardare both used when tracing is enabled and are used for sampled and unsampled traces, respectively, whileIgnoreis used for all traces when tracing is disabled. BothDiscardandIgnoreresult in spans/transactions not being sent to Sentry, but onlyDiscardsends a client report.