Repository navigation
Experiment: Thrown errors passing through startSpan should be associated with first passed through span #16206
Description
Description
Today, an error is only associated with the span that was active at the time captureException(err) was called. This leads to interesting situations like the following:
function foo() {
startSpan({ name: "foo" }, () => { // <-- Error will be associated with this span, even though it was thrown in the "bar" span
try {
bar();
} catch (e) {
captureException(e);
}
});
}
function bar() {
startSpan({ name: "bar" }, () => {
throw new Error();
});
}We could experiment with adding a try-catch to the startSpan wrappers that writes a non-enumerable span ID to errors that pass through (if they didn't have one yet), which is then picked up and preferred by the error processing pipeline over the span ID that is on the scope.
Activity
Lms24 commentedon May 6, 2025
I think this is worthwhile and we should just give it a try. As we discussed offline, there's this bigger picture concern of scope data in general (i.e. the active span is also just the span active on the scope) being lost if you don't manually call
captureExceptionwithin the scope's closure.I found the GH issue where we discussed this on a cross-sdk level: getsentry/sentry-python#2857
The gist is: Technically, we're correct in not appyling any scopes for uncaught or outside-closure-caught errors. It is however unexpected behaviour for a lot of users.
So I'd say we just do it for the span id, see how that is received and learn from it!
test(core): Cover error-to-span attribution for errors escaping a span
test(core): Cover error-to-span attribution for errors escaping a span
fix(core): Attribute errors to the span they escaped (getsentry#23666)
lforst commentedon Sep 10, 2026
big!
github-actions commentedon Sep 23, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #23666, which was included in the 11.0.0 release.