When span streaming is enabled, sentry_sdk.traces.start_span() creates a StreamedSpan but does NOT automatically activate it. The span must be explicitly started via .start() or used as a context manager (with span:). In on_operation(), on_validate(), and on_parse(), the created StreamedSpan objects are never started/entered, causing: (1) spans to never be set as the current scope's span, (2) sampling decisions to never be made for segment spans, (3) child spans to not properly inherit from parent spans. Compare with graphene.py line 158 which correctly calls _graphql_span.start() after creating the span.

The code checks isinstance(span, Span) before calling span.__exit__() for error cleanup. However, when streaming mode is enabled (_experiments={"trace_lifecycle": "stream"}), get_start_span_function() returns a function that creates StreamedSpan instances instead of Span. Since StreamedSpan is not a subclass of Span, this check will always be False for streamed spans, causing the error cleanup code to be silently skipped. This may lead to spans with INTERNAL_ERROR status not being properly closed when using streaming mode.

Also found at:

• sentry_sdk/integrations/anthropic.py:610-612

The _sentry_execute_command function in the async Redis client uses manual __enter__() and __exit__() calls for spans, but unlike the sync version in _sync_common.py, it lacks a try/finally block around await old_execute_command(). If the Redis command raises an exception, db_span.__exit__() and cache_span.__exit__() are never called, leaving spans open. This causes span leakage and incorrect tracing data. The sync version correctly uses try/finally to ensure spans are always closed.

Also found at:

• sentry_sdk/integrations/redis/_sync_common.py:143-150

The json module is imported on line 1 but never used in the file. The _estimate_size method uses str(span_dict) instead of json.dumps() for size approximation. This is likely leftover code from development and won't cause runtime issues, but indicates potential incomplete implementation or dead code.

Also found at:

• sentry_sdk/tracing_utils.py:1058

At line 1273, NoOpStreamedSpan() is returned without the scope=self parameter, unlike the other two NoOpStreamedSpan instances created at lines 1237 and 1255 which pass scope=self. This causes the NoOpStreamedSpan to not participate in scope management (setting/restoring active span on scope context entry/exit), leading to inconsistent behavior compared to other code paths that also return NoOpStreamedSpan.

The _end() method checks self._finished is True before setting self._finished = True at the end. This check-then-act pattern is not atomic. If two threads call end() concurrently on the same span, both could pass the _finished check before either sets it to True, causing the span to be captured twice via scope._capture_span(self). This is a TOCTOU (time-of-check-time-of-use) race condition.