The StreamedSpan class is only imported within the TYPE_CHECKING block (line 30), which means it's not available at runtime. When span streaming is enabled and the code reaches line 167 (if isinstance(_graphql_span, StreamedSpan):), it will raise NameError: name 'StreamedSpan' is not defined. Other integrations like celery/__init__.py and strawberry.py correctly import StreamedSpan at the top level, not just for type checking.

Also found at:

• sentry_sdk/integrations/redis/utils.py:152-160

When sentry_sdk.traces.start_span() is called (lines 216, 231), the returned StreamedSpan is assigned to scope.span but never started via start() or context manager entry. When on_close() later calls finish() (which calls end() -> __exit__()), the span will fail to end properly because _context_manager_state was never set. The error is silently caught by capture_internal_exceptions(), so spans created in streaming mode will never be sent to Sentry.

Each span is serialized via _to_transport_format() twice: once in _estimate_size() during add() for size tracking, and again in _flush() when building the envelope. For high-throughput scenarios with many spans, this doubles the serialization cost. Consider caching the serialized form or computing size from pre-cached data.

The _set_status function receives a status parameter (e.g., "aborted" or "internal_error"), but when the span is a StreamedSpan, it always sets SpanStatus.ERROR instead of using the passed status value. Since StreamedSpan.set_status() accepts Union[SpanStatus, str], it can handle string values directly. This causes control flow exceptions (which should have "aborted" status) to be incorrectly marked as "error", losing the semantic distinction between expected control flow aborts and actual errors.

In _sentry_execute_command, both db_span and cache_span are entered manually via __enter__() but if await old_execute_command(self, name, *args, **kwargs) raises an exception, the corresponding __exit__() calls are never executed. This causes the spans to remain open indefinitely, leading to missing telemetry data and potential memory leaks. The exception info is also not passed to __exit__, so the span status won't reflect the error condition.

Also found at:

• sentry_sdk/integrations/redis/_sync_common.py:135

In the async resolve() method, when self.graphql_span is a StreamedSpan, the code does not call span.set_op(OP.GRAPHQL_RESOLVE) or span.set_origin(StrawberryIntegration.origin). However, the sync resolve() method (lines 357-358) correctly sets both. This inconsistency means async GraphQL resolvers will have incomplete span metadata in streaming mode, potentially affecting trace visualization and filtering in Sentry.

_update_sample_rate_from_segment converts span.sample_rate to string without checking for None. When _set_sampling_decision returns early (e.g., tracing disabled, invalid sample rate, or rate is 0), sample_rate remains None. This causes str(None) = "None" to be stored in baggage's sentry_items["sample_rate"], which propagates an invalid value through trace context that downstream services may fail to parse correctly.

The json module is imported on line 1 but never used in the file. The size estimation uses str(span_dict) and the flush uses PayloadRef(json={...}) which doesn't require the json module directly. This is a minor code quality issue with no runtime impact.

The populate_from_segment method doesn't check if segment._name is truthy before adding it to sentry_items['transaction'], unlike populate_from_transaction which checks if transaction.name. If an empty string is passed as the span name, the baggage will include an empty transaction value, which differs from the original behavior that would skip setting the transaction key entirely.