feat(redis): Support streaming spans #6083
3 issues
find-bugs: Found 3 issues (2 medium, 1 low)
Medium
Spans leak and are never closed when Redis command raises exception - `sentry_sdk/integrations/redis/_async_common.py:145-152`
In _sentry_execute_command, both db_span and cache_span are entered via manual __enter__() calls but if old_execute_command raises an exception (e.g., connection error, timeout), the __exit__() calls on lines 152 and 158 are never reached. This leaves spans in an invalid state on the scope, potentially affecting parent span state and causing resource leaks. The spans should be wrapped in try/finally blocks to ensure proper cleanup.
Also found at:
sentry_sdk/integrations/redis/_sync_common.py:151-160
Test asserts wrong DB_DRIVER_NAME value for streaming spans - `tests/integrations/redis/test_redis.py:405`
The test test_db_connection_attributes_client asserts that attrs[SPANDATA.DB_DRIVER_NAME] equals "redis" for span streaming mode (line 405), but the implementation in sentry_sdk/integrations/redis/modules/queries.py line 55 sets it to "redis-py". This mismatch will cause the test to fail when executed.
Also found at:
tests/integrations/redis/test_redis.py:456
Low
Test assertion checks wrong span index - will always pass trivially - `tests/integrations/redis/test_redis_cache_module_async.py:293`
Line 293 asserts "cache.hit" not in spans[1]["data"] but spans[1] is a db.redis span (as indicated by the comment on line 286), not the cache.put span being tested. The intent is to verify that cache.put operations (spans[2]) don't have a cache.hit attribute. Since db.redis spans never have cache.hit, this assertion always passes trivially and fails to test the actual behavior.
Also found at:
tests/integrations/redis/test_redis_cache_module.py:330
Duration: 7m 44s · Tokens: 4.1M in / 43.1k out · Cost: $6.37 (+extraction: $0.02, +merge: $0.00, +fix_gate: $0.01)
Annotations
Check warning on line 152 in sentry_sdk/integrations/redis/_async_common.py
sentry-warden / warden: find-bugs
Spans leak and are never closed when Redis command raises exception
In `_sentry_execute_command`, both `db_span` and `cache_span` are entered via manual `__enter__()` calls but if `old_execute_command` raises an exception (e.g., connection error, timeout), the `__exit__()` calls on lines 152 and 158 are never reached. This leaves spans in an invalid state on the scope, potentially affecting parent span state and causing resource leaks. The spans should be wrapped in try/finally blocks to ensure proper cleanup.
Check warning on line 160 in sentry_sdk/integrations/redis/_sync_common.py
sentry-warden / warden: find-bugs
[7VG-UTT] Spans leak and are never closed when Redis command raises exception (additional location)
In `_sentry_execute_command`, both `db_span` and `cache_span` are entered via manual `__enter__()` calls but if `old_execute_command` raises an exception (e.g., connection error, timeout), the `__exit__()` calls on lines 152 and 158 are never reached. This leaves spans in an invalid state on the scope, potentially affecting parent span state and causing resource leaks. The spans should be wrapped in try/finally blocks to ensure proper cleanup.
Check warning on line 405 in tests/integrations/redis/test_redis.py
sentry-warden / warden: find-bugs
Test asserts wrong DB_DRIVER_NAME value for streaming spans
The test `test_db_connection_attributes_client` asserts that `attrs[SPANDATA.DB_DRIVER_NAME]` equals `"redis"` for span streaming mode (line 405), but the implementation in `sentry_sdk/integrations/redis/modules/queries.py` line 55 sets it to `"redis-py"`. This mismatch will cause the test to fail when executed.
Check warning on line 456 in tests/integrations/redis/test_redis.py
sentry-warden / warden: find-bugs
[GU5-VQU] Test asserts wrong DB_DRIVER_NAME value for streaming spans (additional location)
The test `test_db_connection_attributes_client` asserts that `attrs[SPANDATA.DB_DRIVER_NAME]` equals `"redis"` for span streaming mode (line 405), but the implementation in `sentry_sdk/integrations/redis/modules/queries.py` line 55 sets it to `"redis-py"`. This mismatch will cause the test to fail when executed.