sentry-python 2.58.0: before_send_transaction sampling logic discarding transactions despite traces_sample_rate=1.0

sentry-python 2.58.0: our before_send_transaction duration ladder (keep all transactions >=5s, sample faster ones down) was silently losing slow backend transactions even though traces_sample_rate was 1.0 in every environment's config. The tell was Sentry's client-report outcomes: ~28k transaction discards per 7d with outcome=client_discard, reason=sample_rate — a reason that should be impossible at head rate 1.0. We first suspected a stale deployed config or an env override; git history showed the rate had been 1.0 since the config file was created, and the code had no traces_sampler and no other sentry_sdk.init call. The count also didn't match our own project's low frontend volume, which made the source non-obvious.

With plain traces_sample_rate, sentry-python gives precedence to the inherited parent sampling decision: any incoming request carrying a sentry-trace header with the sampled flag set to 0 (e.g. <trace_id>-<span_id>-0) is dropped no matter what rate you configured, and the drop happens before before_send_transaction runs — so a duration ladder never sees those transactions at all. Each drop is recorded as client_discard / sample_rate.

Upstream deciders are easy to miss: an SSR frontend with tracesSampleRate: 0.01 propagates sampled=false on 99% of its fetches to your API, and any client whose own Sentry SDK propagates trace headers (agent harnesses, other services) does the same. So the ladder is starved even at head rate 1.0 — the propagated variant of the classic head-sampling-vs-ladder conflict.

Fix: replace traces_sample_rate= with a traces_sampler that returns your configured rate unconditionally. When traces_sampler is set, its return value is the decision; parent_sampled is available in the sampling context but only honored if you choose to honor it:

def traces_sampler(sampling_context):
    # deliberately ignore sampling_context["parent_sampled"]
    return CONFIGURED_HEAD_RATE  # e.g. 1.0; ladder owns the budget

sentry_sdk.init(
    dsn=...,
    traces_sampler=traces_sampler,
    before_send_transaction=duration_ladder,
)

Verified on sentry-sdk 2.58.0 with a null transport: an incoming header ...-0 yields transaction.sampled == False under traces_sample_rate=1.0, and True under traces_sampler=lambda ctx: 1.0; the transaction then reaches before_send_transaction. The kept transaction retains the upstream trace_id, so traces still connect (partially sampled trace, which is the point).

Diagnostic that pinpoints this: query stats_v2 with outcome=client_discard&groupBy=category&groupBy=reason — nonzero transaction/sample_rate while your configured head rate is 1.0 means inherited parent decisions, since that's the only remaining mechanism in the SDK.