The variable span_ctx is declared at line 324 but only assigned inside the capture_internal_exceptions() block (lines 337/360). If an exception occurs after transaction is assigned (e.g., at line 333-335 or 349-359) but before span_ctx is assigned, the exception is suppressed but span_ctx remains unbound. The check at line 362 only verifies transaction is not None, then line 365 with span_ctx: will raise UnboundLocalError, crashing the Celery task execution.

StreamedSpan is imported inside the if TYPE_CHECKING: block (line 30), but it's used in an isinstance() check at runtime (line 167 in graphql_span). When span streaming is enabled and the finally block executes, a NameError: name 'StreamedSpan' is not defined will be raised because the import is not available at runtime.

Also found at:

• sentry_sdk/integrations/stdlib.py:127

In set_transaction_name, the code checks isinstance(self._span, StreamedSpan) and then accesses self._span.segment.set_name(name). However, NoOpStreamedSpan (a subclass of StreamedSpan) sets segment = None in its constructor. Since isinstance() returns True for subclasses, when the current span is a NoOpStreamedSpan, accessing .segment.set_name() will raise AttributeError: 'NoneType' object has no attribute 'set_name'. This can occur when spans are filtered out via is_ignored_span() or when a span has no name.

The async client (lines 186-192) handles baggage headers differently from the sync client. The sync client uses add_sentry_baggage_to_headers() which strips existing Sentry items before appending new ones. The async client simply appends the new baggage without stripping, potentially causing duplicate or conflicting Sentry baggage items in outgoing requests. This inconsistency could lead to trace propagation issues and confusing debugging scenarios.

In _sentry_execute_command, db_span.__enter__() and optionally cache_span.__enter__() are called manually, but if await old_execute_command() raises an exception, __exit__() is never called on either span. This causes spans to leak (never be finished/sent to Sentry) and prevents exception status from being recorded on the spans. The proper context manager protocol requires a try/finally block when using manual __enter__/__exit__ calls.

Also found at:

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

In on_parse(), when span streaming is enabled, sentry_sdk.traces.start_span() is called without the parent_span argument (line 261-262). This is inconsistent with on_validate() which correctly passes parent_span=self.graphql_span. Without the explicit parent, the parsing span will be parented to whatever span is currently active on the scope, which may not be self.graphql_span, resulting in incorrect trace hierarchies.

The async SentryAsyncExtension.resolve() method does not call set_op(OP.GRAPHQL_RESOLVE) or set_origin(StrawberryIntegration.origin) when creating a StreamedSpan, while the sync SentrySyncExtension.resolve() method does. This inconsistency means async GraphQL field resolution spans will lack operation type and origin metadata, making them harder to identify and filter in Sentry's UI.

The end() method (line 376) calls __exit__() which accesses self._context_manager_state (line 347). This attribute is only set during __enter__() (called by start()). If a user creates a span and calls end() without first calling start(), an AttributeError is raised but silently swallowed by capture_internal_exceptions(). The span is never captured and no error is reported to the user, causing silent data loss.

The dynamic_sampling_context() method is inherited from StreamedSpan but not overridden in NoOpStreamedSpan. When called, it executes self.segment.get_baggage().dynamic_sampling_context(). Since NoOpStreamedSpan.__init__ sets self.segment = None, this will raise AttributeError: 'NoneType' object has no attribute 'get_baggage'. Any code that obtains a span and calls dynamic_sampling_context() without checking the span type will crash.

Also found at:

• sentry_sdk/traces.py:576-586

The json module is imported at line 1 but is never used in the file. The only occurrences of 'json' in the file are in content-type strings and as a keyword argument name to PayloadRef, neither of which require the json module. This is dead code that should be removed.

The code uses DeprecationWarning when update_current_span is called in streaming mode, but the API is not deprecated - it's simply unsupported in that mode. DeprecationWarning is semantically incorrect and will be hidden by default in Python's main interpreter (only shown in __main__ and when using -W flags). A UserWarning or RuntimeWarning would be more appropriate and would actually be visible to users.

In the refactored _set_client_data function, the redis.is_cluster tag/attribute was moved inside the if name: block. Previously, redis.is_cluster was set unconditionally at the start of the function. Now, if name is empty or falsy, redis.is_cluster will not be set on the span for either StreamedSpan (using set_attribute) or legacy Span (using set_tag). This is a behavioral regression that could cause missing telemetry data.

In NoOpStreamedSpan.__enter__, line 694 contains scope = self._scope or sentry_sdk.get_current_scope(). The or sentry_sdk.get_current_scope() clause is unreachable because line 691-692 returns early if self._scope is None. This makes the fallback behavior dead code and suggests a potential logic error in scope handling.

The populate_from_segment method does not check if segment._name is truthy before adding it to sentry_items['transaction']. The analogous populate_from_transaction method at line 768-772 checks if (transaction.name and ...) before setting the transaction. If segment._name is an empty string, this will add an empty 'transaction' key to the baggage, which could cause issues with downstream processing.

The function create_streaming_span_decorator imports should_send_default_pii from sentry_sdk.scope on line 1058 but never uses it. This appears to be leftover code from copying the pattern from create_span_decorator (which does use this import on lines 941 and 971/1016). While this is not a security vulnerability, it adds unnecessary import overhead.