feat(redis): Support streaming spans #6083
2 issues
find-bugs: Found 2 issues (2 medium)
Medium
Spans not closed when Redis command raises an exception - `sentry_sdk/integrations/redis/_async_common.py:145-158`
In _sentry_execute_command, spans are manually entered via __enter__() but if old_execute_command raises an exception, neither db_span.__exit__() nor cache_span.__exit__() are called. This leaves spans in an incomplete state (never finished) and leaks span context on the scope. The spans should be wrapped in try/finally to ensure proper cleanup.
Also found at:
sentry_sdk/integrations/redis/_sync_common.py:151-158
Test asserts cache.hit absence on wrong span index - `tests/integrations/redis/test_redis_cache_module.py:330`
Line 330 checks spans[1]["data"] for the absence of cache.hit, but the surrounding assertions (lines 325-329 and 331) all operate on spans[2] which is the cache.put span. spans[1] is a db.redis span (as confirmed by line 323). This test bug means the assertion passes by accident since db.redis spans don't have cache.hit, rather than verifying the intended behavior that cache.put spans should not have cache.hit.
Also found at:
tests/integrations/redis/test_redis_cache_module_async.py:293
Duration: 5m 45s · Tokens: 5.5M in / 49.0k out · Cost: $7.67 (+extraction: $0.02, +merge: $0.00, +fix_gate: $0.01)
Annotations
Check warning on line 158 in sentry_sdk/integrations/redis/_async_common.py
sentry-warden / warden: find-bugs
Spans not closed when Redis command raises an exception
In `_sentry_execute_command`, spans are manually entered via `__enter__()` but if `old_execute_command` raises an exception, neither `db_span.__exit__()` nor `cache_span.__exit__()` are called. This leaves spans in an incomplete state (never finished) and leaks span context on the scope. The spans should be wrapped in try/finally to ensure proper cleanup.
Check warning on line 158 in sentry_sdk/integrations/redis/_sync_common.py
sentry-warden / warden: find-bugs
[DAU-VX8] Spans not closed when Redis command raises an exception (additional location)
In `_sentry_execute_command`, spans are manually entered via `__enter__()` but if `old_execute_command` raises an exception, neither `db_span.__exit__()` nor `cache_span.__exit__()` are called. This leaves spans in an incomplete state (never finished) and leaks span context on the scope. The spans should be wrapped in try/finally to ensure proper cleanup.
Check warning on line 330 in tests/integrations/redis/test_redis_cache_module.py
sentry-warden / warden: find-bugs
Test asserts cache.hit absence on wrong span index
Line 330 checks `spans[1]["data"]` for the absence of `cache.hit`, but the surrounding assertions (lines 325-329 and 331) all operate on `spans[2]` which is the cache.put span. `spans[1]` is a db.redis span (as confirmed by line 323). This test bug means the assertion passes by accident since db.redis spans don't have cache.hit, rather than verifying the intended behavior that cache.put spans should not have cache.hit.
Check warning on line 293 in tests/integrations/redis/test_redis_cache_module_async.py
sentry-warden / warden: find-bugs
[VC6-SH7] Test asserts cache.hit absence on wrong span index (additional location)
Line 330 checks `spans[1]["data"]` for the absence of `cache.hit`, but the surrounding assertions (lines 325-329 and 331) all operate on `spans[2]` which is the cache.put span. `spans[1]` is a db.redis span (as confirmed by line 323). This test bug means the assertion passes by accident since db.redis spans don't have cache.hit, rather than verifying the intended behavior that cache.put spans should not have cache.hit.