[do not merge] feat: Span streaming & new span API #5551
3 issues
code-review: Found 3 issues (1 high, 2 medium)
High
StreamedSpan.set_status() method does not exist - will raise AttributeError - `sentry_sdk/integrations/sqlalchemy.py:102`
The code calls span.set_status(SpanStatus.ERROR) on a StreamedSpan instance, but StreamedSpan class only has a status property setter, not a set_status() method. This will raise AttributeError: 'StreamedSpan' object has no attribute 'set_status' at runtime when a SQL error occurs in streaming mode. The fix should use span.status = SpanStatus.ERROR instead.
Medium
StreamedSpan missing HTTP status code attribute - `sentry_sdk/integrations/httpx.py:117-119`
For StreamedSpan, only span.status ('ok'/'error') and 'reason' attributes are set, but the actual HTTP status code attribute (http.response.status_code) is not set. In contrast, the legacy Span path uses set_http_status() which sets SPANDATA.HTTP_STATUS_CODE. This results in streamed spans missing the numeric HTTP status code, reducing observability for HTTP client requests.
Also found at:
sentry_sdk/integrations/stdlib.py:175-177
Spans not properly closed if Redis command raises exception - `sentry_sdk/integrations/redis/_async_common.py:145`
In _sentry_execute_command, the db_span and cache_span are manually entered with __enter__() but lack try/finally protection around await old_execute_command(). If the Redis command raises an exception, the spans won't be properly closed via __exit__(). This differs from the sync version (_sync_common.py) which correctly uses try/finally. Unclosed spans can cause resource leaks and incorrect span hierarchies in traces.
Also found at:
sentry_sdk/integrations/redis/_sync_common.py:158
Duration: 12m 14s · Tokens: 9.3M in / 106.7k out · Cost: $12.87 (+extraction: $0.01, +merge: $0.00, +fix_gate: $0.00)
Annotations
Check failure on line 102 in sentry_sdk/integrations/sqlalchemy.py
sentry-warden / warden: code-review
StreamedSpan.set_status() method does not exist - will raise AttributeError
The code calls `span.set_status(SpanStatus.ERROR)` on a `StreamedSpan` instance, but `StreamedSpan` class only has a `status` property setter, not a `set_status()` method. This will raise `AttributeError: 'StreamedSpan' object has no attribute 'set_status'` at runtime when a SQL error occurs in streaming mode. The fix should use `span.status = SpanStatus.ERROR` instead.
Check warning on line 119 in sentry_sdk/integrations/httpx.py
sentry-warden / warden: code-review
StreamedSpan missing HTTP status code attribute
For StreamedSpan, only `span.status` ('ok'/'error') and 'reason' attributes are set, but the actual HTTP status code attribute (`http.response.status_code`) is not set. In contrast, the legacy Span path uses `set_http_status()` which sets `SPANDATA.HTTP_STATUS_CODE`. This results in streamed spans missing the numeric HTTP status code, reducing observability for HTTP client requests.
Check warning on line 177 in sentry_sdk/integrations/stdlib.py
sentry-warden / warden: code-review
[DAA-JRE] StreamedSpan missing HTTP status code attribute (additional location)
For StreamedSpan, only `span.status` ('ok'/'error') and 'reason' attributes are set, but the actual HTTP status code attribute (`http.response.status_code`) is not set. In contrast, the legacy Span path uses `set_http_status()` which sets `SPANDATA.HTTP_STATUS_CODE`. This results in streamed spans missing the numeric HTTP status code, reducing observability for HTTP client requests.
Check warning on line 145 in sentry_sdk/integrations/redis/_async_common.py
sentry-warden / warden: code-review
Spans not properly closed if Redis command raises exception
In `_sentry_execute_command`, the `db_span` and `cache_span` are manually entered with `__enter__()` but lack try/finally protection around `await old_execute_command()`. If the Redis command raises an exception, the spans won't be properly closed via `__exit__()`. This differs from the sync version (`_sync_common.py`) which correctly uses try/finally. Unclosed spans can cause resource leaks and incorrect span hierarchies in traces.
Check warning on line 158 in sentry_sdk/integrations/redis/_sync_common.py
sentry-warden / warden: code-review
[4DX-485] Spans not properly closed if Redis command raises exception (additional location)
In `_sentry_execute_command`, the `db_span` and `cache_span` are manually entered with `__enter__()` but lack try/finally protection around `await old_execute_command()`. If the Redis command raises an exception, the spans won't be properly closed via `__exit__()`. This differs from the sync version (`_sync_common.py`) which correctly uses try/finally. Unclosed spans can cause resource leaks and incorrect span hierarchies in traces.