…ing (getsentry#6757) ### Description The SDK didn't behave correctly in some trace propagation scenarios in stream mode. The current SDK design was emitting headers with a deferred sampling decision if the sampling decision was negative (whether inherited or not), because it was falling back to TwP (tracing without performance) behavior too eagerly. Additionally, some edge cases concerning `ignore_spans` and its interaction with sampling were clarified and the necessary changes included in this PR. ## How it should work In the following, _tracing enabled_ means either a `traces_sample_rate` or a `traces_sampler` is defined. _Tracing disabled_ means both are `None` and tracing without performance is active. There are three kinds of sampling decisions: sampled (`1`), unsampled (`0`), and deferred (``), meaning no decision. 1. No incoming trace headers - tracing enabled: make a sampling decision and propagate it - tracing disabled: do not make a decision, propagate a deferred decision (no sampling decision) 2. Incoming trace headers with a sampled/unsampled decision - tracing enabled: respect and propagate incoming decision - tracing disabled: respect and propagate incoming decision 3. Incoming trace headers with a deferred sampling decision (essentially same as 1) - tracing enabled: make a sampling decision and propagate it - tracing disabled: propagate deferred sampling decision ## The problem and the fix If a no-op span was active, we were falling back to the propagation context to generate propagation headers, which by default doesn't contain a sampling decision. With this PR, `NoOpStreamedSpans` now carry their own trace and span ID information as well as the current propagation data (a snapshot of the propagation context, like `StreamedSpans`) and use it to emit the correct headers. This mirrors old behavior: spans would always be created, whether they'd be sampled or not, and they would be responsible for generating propagation headers; with the fallback to the propagation context only kicking in if there is no span. I recommend checking out the new tests to see what behavior is now expected. ## Edge cases The following cases regarding `ignore_spans` were clarified and will be documented soon: - An outgoing request is made from an ignored segment: `sentry-trace` should have an unsampled decision (`-0`), `parent_span_id` is the ID of the segment (or any random span ID, since for all intents and purposes, the ignored segment doesn't actually exist for any downstream service) - An outgoing request is made from an ignored child span of a non-ignored segment: `sentry-trace`'s sampling decision should be the segment's sampling decision; `parent_span_id` should be the first non-ignored span ancestor #### Issues Closes getsentry#6755 #### Reminders - Please add tests to validate your changes, and lint your code using `uv run ruff`. - Add GH Issue ID _&_ Linear ID (if applicable) - PR title should use [conventional commit](https://develop.sentry.dev/engineering-practices/commit-messages/#type) style (`feat:`, `fix:`, `ref:`, `meta:`) - For external contributors: [CONTRIBUTING.md](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md), [Sentry SDK development docs](https://develop.sentry.dev/sdk/), [Discord community](https://discord.gg/Ww9hbqr)

Uh oh!

Sampling decision is deferred when it should be unsampled #6755

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions