In the finally block (lines 153-160), _set_cache_data(cache_span, self, cache_properties, value) references value which is only assigned if old_execute_command succeeds. If the Redis command raises an exception, value is never assigned, causing an UnboundLocalError in the finally block. This crashes the exception handling and masks the original Redis exception, breaking error propagation to callers.

Also found at:

• sentry_sdk/integrations/redis/_async_common.py:126-145

When span streaming mode is enabled and a span is sampled out, a NoOpStreamedSpan is created and set as the active span on the scope. The NoOpStreamedSpan class sets self._segment = None but does not override _get_trace_context() or _dynamic_sampling_context(). When scope.get_trace_context() is called (line 611), it invokes self._span._get_trace_context(). For NoOpStreamedSpan, this inherits from StreamedSpan which calls self._dynamic_sampling_context(), which in turn calls self._segment._get_baggage(). Since _segment is None, this raises AttributeError: 'NoneType' object has no attribute '_get_baggage'.

Also found at:

• sentry_sdk/traces.py:586
• sentry_sdk/integrations/strawberry.py:226

The change from span is not None to isinstance(span, Span) excludes StreamedSpan from the error cleanup logic. When an exception occurs in the Anthropic API call while using span streaming mode, the StreamedSpan will have its status set to SpanStatus.ERROR by set_span_errored(), but the span's __exit__ method is never called. This results in: (1) the span remaining as the current span on the scope (scope pollution), (2) the span never being sent to Sentry since _end() is never called, and (3) potential memory leaks.

Also found at:

• sentry_sdk/integrations/anthropic.py:610

In span streaming mode, when ty is 'http' but the method is NOT in http_methods_to_capture, the code falls through to always create a span (lines 238-240). In non-streaming mode, transaction remains None and no span is created. This causes unwanted tracing of HTTP methods that should be ignored (e.g., OPTIONS, HEAD), creating noise and potentially impacting performance.

The graphql_span context manager manually calls _graphql_span.end() in a finally block instead of using the span as a context manager (with with _graphql_span:). When an exception occurs during the yield (i.e., during GraphQL execution), the StreamedSpan.__exit__ method is not invoked, which means the span's status is never set to SpanStatus.ERROR. This causes telemetry to incorrectly report successful spans even when the operation failed with an exception.

When span streaming mode is enabled, the HTTP status code attribute (http.response.status_code) is never set on the span. The code sets span.status and span.set_attribute("reason", ...) but omits span.set_attribute(SPANDATA.HTTP_STATUS_CODE, rv.status_code). This contrasts with the legacy Span path which calls set_http_status() that sets this attribute. This results in incomplete HTTP span data in streaming mode.

Also found at:

• sentry_sdk/integrations/httpx.py:199-201
• sentry_sdk/integrations/stdlib.py:175-177

In set_transaction_name, when self._span is a NoOpStreamedSpan, the method returns early at line 831, which prevents self._transaction_info["source"] from being updated (lines 845-846). This is scope-level data that should still be set regardless of the span type. Events captured while this scope is active will be missing the transaction source in their transaction_info, causing inconsistent metadata in Sentry.

In is_ignored_span(), when a rule dict contains keys other than 'name' or 'attributes' (e.g., {"foo": "bar"}), both name_matches and attributes_match default to True and are never updated. This causes such rules to match every span, which is almost certainly not the user's intent. While TypedDict provides static type checking, Python doesn't enforce these constraints at runtime.

In sentry_patched_popen_wait, the span name is set to 'subprocess popen' when using span streaming mode (line 322), but this function patches subprocess.Popen.wait and sets the operation to OP.SUBPROCESS_WAIT. The name should be 'subprocess wait' to match the operation and be consistent with the pattern used in sentry_patched_popen_communicate which correctly uses 'subprocess communicate'. This causes incorrect span naming in telemetry data.

The SegmentSource class is imported from sentry_sdk.traces but is never used anywhere in this test file. While not a bug or security issue, this creates unnecessary code complexity and can confuse future maintainers about whether the import was meant to be used in a test that was forgotten.