feat(redis): Support streaming spans #6083
5 issues
Medium
Spans not closed when Redis command raises exception - `sentry_sdk/integrations/redis/_async_common.py:145-152`
In _sentry_execute_command, if old_execute_command raises an exception at line 150, neither db_span.__exit__() (line 152) nor cache_span.__exit__() (line 156) will be called. This leaves spans unclosed, potentially causing them to never be sent to Sentry and potentially leaving scope state corrupted. The spans should be wrapped in try/finally blocks to ensure proper cleanup.
Incorrect span index in assertion checks wrong span's data - `tests/integrations/redis/test_redis_cache_module_async.py:293`
Line 293 asserts "cache.hit" not in spans[1]["data"] but the surrounding context is testing spans[2] (the cache.put span). This assertion inadvertently checks the db.redis span at index 1 instead of the cache.put span at index 2, making the test less meaningful as it doesn't verify the expected span's attributes.
Also found at:
tests/integrations/redis/test_redis_cache_module.py:330
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
Low
send_default_pii parameter not verified in span_streaming test path - `tests/integrations/redis/asyncio/test_redis_asyncio.py:66-89`
In test_async_redis_pipeline, when span_streaming=True, the send_default_pii parameter is passed to sentry_init but the streaming branch makes no assertions related to PII filtering behavior. The expected_first_ten parameter (which validates PII filtering of command arguments) is completely ignored in the streaming path. This means PII filtering in streaming mode is not being tested, only whether spans are created with correct attributes.
4 skills analyzed
| Skill | Findings | Duration | Cost |
|---|---|---|---|
| code-review | 3 | 3m 9s | $3.80 |
| find-bugs | 2 | 9m 3s | $6.54 |
| skill-scanner | 0 | 4m 8s | $1.62 |
| security-review | 0 | 5m 20s | $1.74 |
Duration: 21m 41s · Tokens: 8.5M in / 96.9k out · Cost: $13.75 (+extraction: $0.01, +merge: $0.00, +fix_gate: $0.01, +dedup: $0.02)