fix(tracing): Discard invalid navigation transactions via event processor#6051
fix(tracing): Discard invalid navigation transactions via event processor#6051
Conversation
…ssor
Previously, the SDK discarded "invalid" navigation/interaction root spans
(empty back-navigations, route-change transactions that never received route
info, childless idle transactions, and the latest navigation span on RN
Navigation / React Navigation timeouts) by mutating the private `_sampled`
flag on the SentrySpan. This caused @sentry/core to treat the transactions
as sampled-out, producing misleading "dropped due to sampling" debug logs
and incorrect client-report reasons even when `tracesSampleRate=1.0`.
Switch to a proper event-processor-based discard:
- Mark the root span with a new `sentry.rn.discard_reason` attribute
(`empty_back_navigation`, `no_route_info`, `no_child_spans`, or
`discarded_latest_navigation`) and end it normally with its real sampling
decision.
- The `reactNativeTracingIntegration` event processor now filters out any
transaction event carrying that attribute, returning `null` and reporting
`recordDroppedEvent('event_processor', 'transaction')`.
- The app start integration's lock-reset check looks for the discard marker
instead of `!spanIsSampled`, so app start data still attaches to the next
real transaction after a discarded one.
Tests cover the four discard sites, the event processor (drop / pass /
non-transaction passthrough), and update the existing `_sampled`-based
expectations to assert the new attribute and that the sampling flag is
preserved.
Refs: #4431
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5eb6f69. Configure here.
| client.recordDroppedEvent('event_processor', 'transaction'); | ||
| return null; | ||
| } | ||
| } |
There was a problem hiding this comment.
Possible double counting of dropped transaction events
Low Severity
When the event processor returns null, @sentry/core typically auto-records a dropped event with reason event_processor for the corresponding category. The processor here also explicitly calls client.recordDroppedEvent('event_processor', 'transaction') before returning null, which can lead to the same dropped transaction being counted twice in client reports/outcomes telemetry.
Reviewed by Cursor Bugbot for commit 5eb6f69. Configure here.
1 participant
📢 Type of change
📜 Description
Fixes #4431
Our SDK was previously discarding the "invalid" root spans by changing
_sampledtofalsewhich was a bit of a hack. This PR switches to proper handling instead with the following changes:sentry.rn.discard_reasonattribute;reactNativeTracingIntegrationevent processor now filters out any transaction event with this attribute, returningnulland callingrecordDroppedEvent('event_processor', 'transaction').!spanIsSampled, so app start data still attaches to the next real transaction after a discarded one.💚 How did you test it?
A few tests has been added.
📝 Checklist
sendDefaultPIIis enabled🔮 Next steps