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 _sentry_execute_command, the calls to set_db_data_fn(db_span, self) and _set_client_data(db_span, is_cluster, name, *args) are not wrapped in capture_internal_exceptions(). The synchronous counterpart in _sync_common.py wraps these calls (lines 147-149). If these functions raise an exception, it will propagate and could cause the Redis command to fail or leave spans unclosed, affecting user operations.

Line 293 asserts "cache.hit" not in spans[1]["data"] but spans[1] is a db.redis span (confirmed at line 286), not the cache.put span being tested. The surrounding assertions (lines 288-294) are testing properties of spans[2] (the cache.put span), but this one accidentally references spans[1]. This makes the assertion trivially pass since db.redis spans never have cache.hit, defeating the intended test that cache.put operations shouldn't set cache.hit.

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.