Skip to content

fix: Introduce _get_current_streamed_span() to keep types backwards compatible #6177

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
alexander-alderman-webb merged 16 commits into from
Apr 30, 2026

limit api to traces.py and mark private

11fe228
Select commit
Loading
Failed to load commit list.
Merged

fix: Introduce _get_current_streamed_span() to keep types backwards compatible #6177

limit api to traces.py and mark private
11fe228
Select commit
Loading
Failed to load commit list.
@sentry/warden / warden: find-bugs completed Apr 30, 2026 in 1m 27s

1 issue

find-bugs: Found 1 issue (1 medium)

Medium

streamed_span setter unconditionally overwrites self._span, can clobber an existing Span - `sentry_sdk/scope.py:917`

The new streamed_span setter assigns self._span = span without checking what is currently stored. If the scope currently holds a Span (transaction-mode) and any caller assigns scope.streamed_span = None or a StreamedSpan, the existing Span is silently destroyed. The same asymmetry exists on the span setter for an existing StreamedSpan. Because Scope.span and Scope.streamed_span are documented as type-discriminated views over the same underlying _span, callers reasonably assume that touching one will not affect the other; this assumption does not hold and can lead to lost spans/transactions when both lifecycles are mixed.

Duration: 1m 26s · Tokens: 868.7k in / 12.5k out · Cost: $3.82 (+extraction: $0.00)

Annotations

Check warning on line 917 in sentry_sdk/scope.py

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: find-bugs

streamed_span setter unconditionally overwrites self._span, can clobber an existing Span 

The new `streamed_span` setter assigns `self._span = span` without checking what is currently stored. If the scope currently holds a `Span` (transaction-mode) and any caller assigns `scope.streamed_span = None` or a StreamedSpan, the existing `Span` is silently destroyed. The same asymmetry exists on the `span` setter for an existing `StreamedSpan`. Because `Scope.span` and `Scope.streamed_span` are documented as type-discriminated views over the same underlying `_span`, callers reasonably assume that touching one will not affect the other; this assumption does not hold and can lead to lost spans/transactions when both lifecycles are mixed.
View more details on @sentry/warden