In sentry_patched_execute_command, if old_execute_command raises an exception, the finally block will attempt to access value in the call to _set_cache_data(cache_span, self, cache_properties, value), but value was never assigned. This causes an UnboundLocalError: local variable 'value' referenced before assignment, which will crash the application instead of propagating the original Redis exception.

Also found at:

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

The code calls span.set_status(SpanStatus.ERROR) on line 102 when the span is a StreamedSpan. However, StreamedSpan class (defined in sentry_sdk/traces.py) does not have a set_status() method - it only has a status property setter. This will raise an AttributeError at runtime when a SQL error occurs in streaming mode. The fix should use property assignment: span.status = SpanStatus.ERROR.

Also found at:

• sentry_sdk/integrations/graphene.py:174-175

The code calls span.set_status(SpanStatus.ERROR) when span is a StreamedSpan, but StreamedSpan class does not have a set_status method. It only has a status property setter. When a SQL error occurs in streaming mode, this will raise an AttributeError: 'StreamedSpan' object has no attribute 'set_status', preventing proper error handling and potentially breaking the application.

When using span streaming mode, the HTTP status code (e.g., 200, 404, 500) is not recorded as an attribute on the span. Only the status ('ok'/'error') and 'reason' are set. Compare with wsgi.py line 235 which correctly calls span.set_attribute("http.response.status_code", status_int) for StreamedSpan. This results in data loss - users won't see the actual HTTP status code in their traces when using span streaming mode.

When span streaming is enabled, the StreamedSpan sets span.status and reason attribute but does NOT set the HTTP status code attribute (SPANDATA.HTTP_STATUS_CODE / http.response.status_code). The legacy Span.set_http_status() method sets this attribute at line 635 of sentry_sdk/tracing.py. This results in incomplete span telemetry data - users won't see the actual HTTP status code in their traces when using span streaming mode.

Also found at:

• sentry_sdk/integrations/httpx.py:200-202
• sentry_sdk/integrations/stdlib.py:175-177

When old_execute_command raises an exception, the value variable is never assigned. The finally block then attempts to use value in _set_cache_data(cache_span, self, cache_properties, value), causing a NameError. While wrapped in capture_internal_exceptions(), this silently loses cache span metadata and may cause confusing internal error logs.

Also found at:

• sentry_sdk/integrations/strawberry.py:226

The sentry_patched_popen_wait function incorrectly sets the span name to 'subprocess popen' when it should be 'subprocess wait' to match the OP.SUBPROCESS_WAIT operation and the method being wrapped. This inconsistency will make it harder to identify subprocess.wait spans in the Sentry UI, as the span name won't match the operation being performed.

In sentry_patched_popen_wait, the span name is set to 'subprocess popen' (line 322) while the operation is OP.SUBPROCESS_WAIT (line 323). This appears to be a copy-paste error. The other subprocess functions use consistent naming: 'subprocess communicate' with SUBPROCESS_COMMUNICATE. This inconsistency will cause confusion when analyzing traces since the span name doesn't match the actual operation being performed.