Summary
The SDK appears to conflate "Tracing without Performance" (no tracing config) with traces_sample_rate = 0. Per the trace propagation spec, those cases must behave differently: default propagation should continue and propagate traces with deferred sampling, while an explicit zero sample rate should propagate with sampled=0.
A closed earlier issue, #796, tracked TwP broadly. The remaining gap appears to be that the default SDK state behaves like explicit zero sampling instead of TwP. In practice, this likely means new traces are propagated as sentry-trace: <trace_id>-<span_id>-0 where the spec expects deferred propagation (<trace_id>-<span_id>), and incoming deferred traces may be turned into negative sampling decisions instead of staying deferred.
Expected behavior
When tracing is not configured:
- continue incoming traces and keep deferred sampling deferred;
- start new traces with a propagation context but no sampling decision;
- propagate
sentry-trace without the sampled suffix for deferred traces;
- keep the explicit
traces_sample_rate = 0 behavior distinct, with negative sampling decisions.
If transactionless scope-based continuation is still missing, that should be handled as part of this work or split into a follow-up issue, but the main observable spec mismatch is the missing deferred propagation behavior.
Implementation note
This likely requires a breaking public API change in ClientOptions. The current API shape appears to encode tracing configuration as a concrete numeric sample rate, which makes the default state behave like traces_sample_rate = 0 rather than "tracing not configured". To represent the spec distinction correctly, the client options likely need a way to distinguish an absent tracing configuration from an explicit zero sample rate, potentially by changing the type of traces_sample_rate or by introducing another explicit configuration state.
Summary
The SDK appears to conflate "Tracing without Performance" (no tracing config) with
traces_sample_rate = 0. Per the trace propagation spec, those cases must behave differently: default propagation should continue and propagate traces with deferred sampling, while an explicit zero sample rate should propagate withsampled=0.A closed earlier issue, #796, tracked TwP broadly. The remaining gap appears to be that the default SDK state behaves like explicit zero sampling instead of TwP. In practice, this likely means new traces are propagated as
sentry-trace: <trace_id>-<span_id>-0where the spec expects deferred propagation (<trace_id>-<span_id>), and incoming deferred traces may be turned into negative sampling decisions instead of staying deferred.Expected behavior
When tracing is not configured:
sentry-tracewithout the sampled suffix for deferred traces;traces_sample_rate = 0behavior distinct, with negative sampling decisions.If transactionless scope-based continuation is still missing, that should be handled as part of this work or split into a follow-up issue, but the main observable spec mismatch is the missing deferred propagation behavior.
Implementation note
This likely requires a breaking public API change in
ClientOptions. The current API shape appears to encode tracing configuration as a concrete numeric sample rate, which makes the default state behave liketraces_sample_rate = 0rather than "tracing not configured". To represent the spec distinction correctly, the client options likely need a way to distinguish an absent tracing configuration from an explicit zero sample rate, potentially by changing the type oftraces_sample_rateor by introducing another explicit configuration state.