When old_execute_command raises an exception and a cache_span exists, the finally block attempts to access value in _set_cache_data(cache_span, self, cache_properties, value) before it's assigned. This causes an UnboundLocalError that replaces the original Redis exception, making it impossible to debug the actual failure cause.

Also found at:

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

The code calls span.set_status(SpanStatus.ERROR) when the span is a StreamedSpan instance (line 102). However, the StreamedSpan class in sentry_sdk/traces.py does not have a set_status() method - it only has a status property setter. The legacy Span class has set_status() (line 600 in tracing.py), but StreamedSpan does not, so this will raise an AttributeError at runtime when handling SQL errors in streaming mode.

The code at line 102 calls span.set_status(SpanStatus.ERROR) on a StreamedSpan object, but StreamedSpan class does not have a set_status() method. Unlike the legacy Span class which has set_status(), StreamedSpan only provides a status property setter. This will cause an AttributeError at runtime when span streaming mode is enabled and a SQL error occurs.

Also found at:

• sentry_sdk/integrations/strawberry.py:226

The changes introduce significant branching logic to handle both legacy and span streaming modes in apply_async and _wrap_tracer functions. However, there are no tests in tests/integrations/celery/ that exercise the new span streaming code paths (checked by searching for trace_lifecycle and span_streaming patterns). Without integration tests covering the span streaming mode, regressions in Celery task tracing could go undetected.

When handling HTTP responses with StreamedSpan, the code sets span.status and the reason attribute but does not set the HTTP status code attribute (SPANDATA.HTTP_STATUS_CODE). The legacy path correctly calls set_http_status() which sets http.response.status_code. This inconsistency means that HTTP response status codes will be missing from spans in streaming mode, reducing observability of HTTP client calls.

When using span streaming mode, the HTTP response status code is not captured as an attribute. Lines 116-118 set span.status to 'ok' or 'error' and add a 'reason' attribute, but unlike the legacy set_http_status() path (line 120) or the ASGI integration (which sets http.response.status_code), the actual numeric status code is never recorded. This causes data loss - users cannot see the specific HTTP status code (e.g., 404 vs 500) in their telemetry.

Also found at:

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

In _sentry_execute_command, the db_span and cache_span are manually entered with __enter__() but are not protected by a try/finally block. If old_execute_command(self, name, *args, **kwargs) raises an exception, __exit__() is never called on either span. This causes span leaks and leaves the scope in an inconsistent state (the span remains as the active span on the scope). The sync version in _sync_common.py correctly uses try/finally for this (lines 151-160).

Also found at:

• sentry_sdk/integrations/redis/_sync_common.py:158

The code imports Pattern unconditionally from typing on line 13, then immediately tries to import it again from re in the try/except block on lines 15-19. This results in the re.Pattern import (when successful in Python 3.7+) shadowing the typing.Pattern import. While not a runtime error, this redundancy is confusing and the unconditional typing import on line 13 serves no purpose.