If old_execute_command() on line 151 raises an exception, db_span.__exit__() and cache_span.__exit__() are never called. This leaves spans in an unclosed state, causing resource leaks in span tracking and missing span data. The spans should be wrapped in try/finally to ensure proper cleanup regardless of exceptions.

Also found at:

• sentry_sdk/integrations/redis/_async_common.py:147-148

Line 293 asserts "cache.hit" not in spans[1]["data"] but should be checking spans[2]. The surrounding code (lines 288-294) is testing the cache.put span at index 2, and spans[1] is the db.redis span (per line 286 comment). Since db.redis spans never have cache.hit, this assertion always passes regardless of whether the cache.put span incorrectly contains cache.hit. The test fails to validate the actual requirement.

Also found at:

• tests/integrations/redis/test_redis_cache_module.py:330

In test_rediscluster_pipeline, the expected_first_ten parameter (which validates redis.commands.first_ten with potentially filtered PII) is only used in the non-streaming path (line 207). The streaming path (lines 182-189) doesn't verify that command data is properly included or filtered based on send_default_pii. This may result in insufficient test coverage for PII filtering in streaming mode.