Diagnose: transactions missing from Sentry

# Diagnose: transactions missing from Sentry

## Step 1: is tracing enabled at all?

Either `traces_sample_rate` or `traces_sampler` must be set, or tracing is off entirely. Unset is the most common cause. Note the zero semantics: `0` starts no new traces (incoming distributed traces still continue), `None`/unset disables tracing completely.

## Step 2: is there a transaction source?

Sampled or not, spans need a transaction to live in. Framework integrations (Django, Express, Rails) create them per request automatically. Outside those, a plain script or worker with a sample rate but no `start_transaction`/`startSpan` produces nothing. Add one manual transaction around the work and retest.

## Step 3: v11 stream-mode filters

If transactions vanished after a JS SDK upgrade, check for `beforeSendTransaction` and `ignoreTransactions`: in stream mode they are never called. Port the logic to `beforeSendSpan` (which receives the renamed StreamedSpanJSON payload: `name` not `description`, `attributes` not `data`) or `ignoreSpans`.

## Step 4: is it sampled out?

With debug on, the SDK logs whether a transaction was sampled. A 0.01 rate on a low-traffic endpoint means waiting a long time for one trace. Temporarily raise to 1.0 in dev to confirm the pipeline, then lower it again.

## Step 5: quota

Spans are their own quota category. An exhausted span quota 429s transactions while errors keep flowing, which looks exactly like a tracing bug.

## Verify

One request producing one transaction with child spans, linked to its error if the request also raised. If spans arrive but carry no custom attributes you set via setTag, remember v11 needs setAttribute for span attributes.