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.

StreamedSpan is imported under TYPE_CHECKING (line 30) but is used in an isinstance() check at runtime (line 167). When span streaming mode is enabled, executing a GraphQL query will raise NameError: name 'StreamedSpan' is not defined when the code reaches the finally block.

Also found at:

• sentry_sdk/integrations/anthropic.py:572-574

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.

When size + 1 >= self.MAX_BEFORE_FLUSH (line 68), the span is added to _span_buffer at line 66 but the function returns at line 70 without updating _running_size. This means the byte size of that span is never tracked. If the flush thread is delayed or another span arrives before the flush completes, the byte-size tracking will undercount the actual buffer size, potentially allowing more data to accumulate than intended before a byte-based flush.

Also found at:

• sentry_sdk/integrations/celery/__init__.py:330-337

The async httpx client uses inline baggage handling (lines 186-192) that differs from the sync client's add_sentry_baggage_to_headers() helper. The async implementation appends baggage with += without first stripping existing sentry items, while the sync client properly strips them. This can cause duplicate sentry baggage items when outgoing requests already have sentry-prefixed baggage, potentially causing parsing issues or exceeding header size limits on downstream services.