feat(redis): Support streaming spans #6083
2 issues
find-bugs: Found 2 issues (2 medium)
Medium
Span leak and missing error status when Redis command raises exception - `sentry_sdk/integrations/redis/_async_common.py:145-147`
When await old_execute_command() raises an exception (e.g., connection error, timeout), the manually invoked db_span.__exit__(None, None, None) and cache_span.__exit__(None, None, None) calls are bypassed. This causes spans to never be closed (leaked resources, incorrect timing) and error status is not set on the span since __exit__ receives None values instead of exception info. The same issue exists in both async and sync Redis client patching.
Also found at:
sentry_sdk/integrations/redis/_sync_common.py:126-145
Test assertion checks wrong span index for cache.hit verification - `tests/integrations/redis/test_redis_cache_module_async.py:293`
On line 293, the assertion assert "cache.hit" not in spans[1]["data"] checks spans[1] (which is a db.redis span) instead of spans[2] (which is the cache.put span). The surrounding context on lines 288-294 is clearly testing the cache.put span at index 2, but this single assertion accidentally checks the wrong index. 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.py:330
Duration: 9m 3s · Tokens: 4.3M in / 42.2k out · Cost: $6.55 (+extraction: $0.00, +merge: $0.00, +fix_gate: $0.00)
Annotations
Check warning on line 147 in sentry_sdk/integrations/redis/_async_common.py
sentry-warden / warden: find-bugs
Span leak and missing error status when Redis command raises exception
When `await old_execute_command()` raises an exception (e.g., connection error, timeout), the manually invoked `db_span.__exit__(None, None, None)` and `cache_span.__exit__(None, None, None)` calls are bypassed. This causes spans to never be closed (leaked resources, incorrect timing) and error status is not set on the span since `__exit__` receives `None` values instead of exception info. The same issue exists in both async and sync Redis client patching.
Check warning on line 145 in sentry_sdk/integrations/redis/_sync_common.py
sentry-warden / warden: find-bugs
[LZ5-ZCS] Span leak and missing error status when Redis command raises exception (additional location)
When `await old_execute_command()` raises an exception (e.g., connection error, timeout), the manually invoked `db_span.__exit__(None, None, None)` and `cache_span.__exit__(None, None, None)` calls are bypassed. This causes spans to never be closed (leaked resources, incorrect timing) and error status is not set on the span since `__exit__` receives `None` values instead of exception info. The same issue exists in both async and sync Redis client patching.
Check warning on line 293 in tests/integrations/redis/test_redis_cache_module_async.py
sentry-warden / warden: find-bugs
Test assertion checks wrong span index for cache.hit verification
On line 293, the assertion `assert "cache.hit" not in spans[1]["data"]` checks `spans[1]` (which is a `db.redis` span) instead of `spans[2]` (which is the `cache.put` span). The surrounding context on lines 288-294 is clearly testing the cache.put span at index 2, but this single assertion accidentally checks the wrong index. This causes the test to not actually verify that cache.put spans lack the cache.hit attribute.
Check warning on line 330 in tests/integrations/redis/test_redis_cache_module.py
sentry-warden / warden: find-bugs
[9QN-MPB] Test assertion checks wrong span index for cache.hit verification (additional location)
On line 293, the assertion `assert "cache.hit" not in spans[1]["data"]` checks `spans[1]` (which is a `db.redis` span) instead of `spans[2]` (which is the `cache.put` span). The surrounding context on lines 288-294 is clearly testing the cache.put span at index 2, but this single assertion accidentally checks the wrong index. This causes the test to not actually verify that cache.put spans lack the cache.hit attribute.