fix(core): Catch beforeSendSpan callback throws - #22836
Conversation
size-limit report 📦
|
962dbc1 to
7de446c
Compare
2b3d3e2 to
192e001
Compare
7de446c to
74a1167
Compare
192e001 to
f1557e3
Compare
74a1167 to
ee4761d
Compare
cd95b76 to
b5688d4
Compare
b568562 to
a43fe54
Compare
b5688d4 to
214a5f3
Compare
a43fe54 to
a3e7446
Compare
214a5f3 to
8eda355
Compare
8eda355 to
91dd535
Compare
beforeSendSpan callback escape into user codebeforeSendSpan callback throws
61f06d4 to
8745c98
Compare
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.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 8745c98. Configure here.
| } | ||
| const processedRootSpanJson = applyBeforeSendSpanCallback(rootSpanJson, beforeSendSpan); | ||
| // update event with processed root span values | ||
| processedEvent = merge(event, convertSpanJsonToTransactionEvent(processedRootSpanJson)); |
There was a problem hiding this comment.
Unmodified root span still merged
Low Severity
When beforeSendSpan throws or returns null for the root span, applyBeforeSendSpanCallback correctly hands back the original span JSON, but the caller always merges the convert round-trip into the transaction. Previously a null return left the event untouched. Because merge replaces contexts.trace wholesale and the converters apply defaults, the “unmodified” fallback can still alter the event.
Reviewed by Cursor Bugbot for commit 8745c98. Configure here.
There was a problem hiding this comment.
yeah I'm willing to take this risk. mutating the originally passed in json is not something we directly recommend but we should still expected. It might even be advantageous here: If users scrub first, and then decide to return null, the scrubbing still gets applied if they mutate in-place. This should be fine to change, especially in v11. I'm not planning on backporting this PR anyway.
… user code Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
8745c98 to
282d43b
Compare


This PR wraps the
beforeSendSpancallback application incaptureSpan,captureStandaloneSpanWithStaticCallbackand core client transactionbeforeSendSpaninvocations in a try/catch. The error is logged and the span is sent unmodified to Sentry.Spans are captured synchronously from the
afterSpanEndhook, so a throwing callback propagates straight out of whatever user code calledspan.end(). Especially with the requiredbeforeSendSpanmigration fromSpanJSONtoStreamedSpanJSON, this is quite likely to happen.We want to apply similar guards to more user-facing callbacks in the future, so we might be able to reuse/adjust the
applyBeforeSendSpanhelper to more functionality later on.