feat(redis): Support streaming spans #6083
2 issues
find-bugs: Found 2 issues (2 medium)
Medium
Spans not properly closed on exception in _sentry_execute_command - `sentry_sdk/integrations/redis/_async_common.py:126-156`
In _sentry_execute_command, spans are opened via manual __enter__() calls (lines 126, 145) but their corresponding __exit__() calls (lines 152, 156) are not wrapped in try/finally. If old_execute_command raises an exception at line 150, both db_span and cache_span will never be closed, resulting in spans not being sent to Sentry, error status not being recorded, and the scope's span reference not being restored.
Also found at:
sentry_sdk/integrations/redis/_sync_common.py:145-147
Test assertion checks wrong span index - verifies db.redis instead of cache.put - `tests/integrations/redis/test_redis_cache_module.py:330`
Line 330 asserts "cache.hit" not in spans[1]["data"] but spans[1] is the db.redis span (confirmed by line 323), not the cache.put span at spans[2]. The surrounding code context (lines 325-331) is testing the cache.put span properties, but this assertion mistakenly verifies the db.redis span. This causes the test to not actually verify that cache.put spans lack the cache.hit attribute.
Also found at:
tests/integrations/redis/test_redis_cache_module_async.py:293
Duration: 4m 15s · Tokens: 4.5M in / 43.0k out · Cost: $6.77 (+extraction: $0.01, +merge: $0.00, +fix_gate: $0.01)
Annotations
Check warning on line 156 in sentry_sdk/integrations/redis/_async_common.py
sentry-warden / warden: find-bugs
Spans not properly closed on exception in _sentry_execute_command
In `_sentry_execute_command`, spans are opened via manual `__enter__()` calls (lines 126, 145) but their corresponding `__exit__()` calls (lines 152, 156) are not wrapped in try/finally. If `old_execute_command` raises an exception at line 150, both `db_span` and `cache_span` will never be closed, resulting in spans not being sent to Sentry, error status not being recorded, and the scope's span reference not being restored.
Check warning on line 147 in sentry_sdk/integrations/redis/_sync_common.py
sentry-warden / warden: find-bugs
[UNR-74R] Spans not properly closed on exception in _sentry_execute_command (additional location)
In `_sentry_execute_command`, spans are opened via manual `__enter__()` calls (lines 126, 145) but their corresponding `__exit__()` calls (lines 152, 156) are not wrapped in try/finally. If `old_execute_command` raises an exception at line 150, both `db_span` and `cache_span` will never be closed, resulting in spans not being sent to Sentry, error status not being recorded, and the scope's span reference not being restored.
Check warning on line 330 in tests/integrations/redis/test_redis_cache_module.py
sentry-warden / warden: find-bugs
Test assertion checks wrong span index - verifies db.redis instead of cache.put
Line 330 asserts `"cache.hit" not in spans[1]["data"]` but spans[1] is the db.redis span (confirmed by line 323), not the cache.put span at spans[2]. The surrounding code context (lines 325-331) is testing the cache.put span properties, but this assertion mistakenly verifies the db.redis span. This causes the test to not actually verify that cache.put spans lack the cache.hit attribute.
Check warning on line 293 in tests/integrations/redis/test_redis_cache_module_async.py
sentry-warden / warden: find-bugs
[PWH-5KJ] Test assertion checks wrong span index - verifies db.redis instead of cache.put (additional location)
Line 330 asserts `"cache.hit" not in spans[1]["data"]` but spans[1] is the db.redis span (confirmed by line 323), not the cache.put span at spans[2]. The surrounding code context (lines 325-331) is testing the cache.put span properties, but this assertion mistakenly verifies the db.redis span. This causes the test to not actually verify that cache.put spans lack the cache.hit attribute.