fix: Introduce _get_current_streamed_span() to keep types backwards compatible
#6177
1 issue
find-bugs: Found 1 issue (1 medium)
Medium
span.setter silently drops StreamedSpan segment metadata, breaking runtime backwards compatibility - `sentry_sdk/scope.py:887-896`
The previous span.setter accepted Union[Span, StreamedSpan] and, when given a StreamedSpan segment, populated self._transaction and self._transaction_info from the span's name and 'sentry.span.source' attribute. The new span.setter only handles Transaction and silently ignores StreamedSpan inputs at runtime. Although the type annotation is now Optional[Span], existing callers (integrations, user code, third-party code) that still assign a StreamedSpan via scope.span = streamed_span will no longer have transaction metadata populated, causing events to be missing transaction names/sources and breaking segment linkage in streaming mode. The PR's stated goal is backwards compatibility, but this is only type-level — runtime behavior regressed.
Duration: 44.4s · Tokens: 130.0k in / 2.1k out · Cost: $0.68
Annotations
Check warning on line 896 in sentry_sdk/scope.py
sentry-warden / warden: find-bugs
span.setter silently drops StreamedSpan segment metadata, breaking runtime backwards compatibility
The previous span.setter accepted Union[Span, StreamedSpan] and, when given a StreamedSpan segment, populated self._transaction and self._transaction_info from the span's name and 'sentry.span.source' attribute. The new span.setter only handles Transaction and silently ignores StreamedSpan inputs at runtime. Although the type annotation is now Optional[Span], existing callers (integrations, user code, third-party code) that still assign a StreamedSpan via scope.span = streamed_span will no longer have transaction metadata populated, causing events to be missing transaction names/sources and breaking segment linkage in streaming mode. The PR's stated goal is backwards compatibility, but this is only type-level — runtime behavior regressed.