feat(redis): Support streaming spans #6083
2 issues
find-bugs: Found 2 issues (2 medium)
Medium
Redis spans not properly closed when command raises an exception - `sentry_sdk/integrations/redis/_async_common.py:145-156`
In _sentry_execute_command, spans are entered via __enter__() but exit is only called via __exit__(None, None, None) after the command succeeds. If old_execute_command raises an exception (e.g., Redis connection error, timeout), db_span.__exit__() and cache_span.__exit__() are never called. This causes the span to remain unfinished, leaves the scope's active span in an inconsistent state, and prevents proper error status from being recorded on the span.
Also found at:
sentry_sdk/integrations/redis/_sync_common.py:145-156
Test checks wrong span index for cache.hit assertion - `tests/integrations/redis/test_redis_cache_module.py:331`
Line 331 asserts "cache.hit" not in spans[1]["data"] but spans[1] is a db.redis span (confirmed at line 324), not the cache.put span being validated. The assertion should reference spans[2] (the cache.put span identified at line 326) to actually verify that cache.put spans don't have a cache.hit attribute. This bug means the test is passing vacuously since db.redis spans don't have cache data.
Also found at:
tests/integrations/redis/test_redis_cache_module_async.py:293
Duration: 7m 37s · Tokens: 4.6M in / 43.1k out · Cost: $6.71 (+extraction: $0.01, +merge: $0.00, +fix_gate: $0.00)
Annotations
Check warning on line 156 in sentry_sdk/integrations/redis/_async_common.py
sentry-warden / warden: find-bugs
Redis spans not properly closed when command raises an exception
In `_sentry_execute_command`, spans are entered via `__enter__()` but exit is only called via `__exit__(None, None, None)` after the command succeeds. If `old_execute_command` raises an exception (e.g., Redis connection error, timeout), `db_span.__exit__()` and `cache_span.__exit__()` are never called. This causes the span to remain unfinished, leaves the scope's active span in an inconsistent state, and prevents proper error status from being recorded on the span.
Check warning on line 156 in sentry_sdk/integrations/redis/_sync_common.py
sentry-warden / warden: find-bugs
[U86-9ML] Redis spans not properly closed when command raises an exception (additional location)
In `_sentry_execute_command`, spans are entered via `__enter__()` but exit is only called via `__exit__(None, None, None)` after the command succeeds. If `old_execute_command` raises an exception (e.g., Redis connection error, timeout), `db_span.__exit__()` and `cache_span.__exit__()` are never called. This causes the span to remain unfinished, leaves the scope's active span in an inconsistent state, and prevents proper error status from being recorded on the span.
Check warning on line 331 in tests/integrations/redis/test_redis_cache_module.py
sentry-warden / warden: find-bugs
Test checks wrong span index for cache.hit assertion
Line 331 asserts `"cache.hit" not in spans[1]["data"]` but `spans[1]` is a `db.redis` span (confirmed at line 324), not the `cache.put` span being validated. The assertion should reference `spans[2]` (the cache.put span identified at line 326) to actually verify that cache.put spans don't have a cache.hit attribute. This bug means the test is passing vacuously since db.redis spans don't have cache data.
Check warning on line 293 in tests/integrations/redis/test_redis_cache_module_async.py
sentry-warden / warden: find-bugs
[G4R-SUJ] Test checks wrong span index for cache.hit assertion (additional location)
Line 331 asserts `"cache.hit" not in spans[1]["data"]` but `spans[1]` is a `db.redis` span (confirmed at line 324), not the `cache.put` span being validated. The assertion should reference `spans[2]` (the cache.put span identified at line 326) to actually verify that cache.put spans don't have a cache.hit attribute. This bug means the test is passing vacuously since db.redis spans don't have cache data.