In sentry_patched_execute_command, spans are entered with __enter__() and exited with __exit__() manually, but if old_execute_command() raises an exception, __exit__() is never called for either db_span or cache_span. This leaves spans unclosed when Redis commands fail, which causes resource leaks and incorrect span hierarchies. The patch_redis_pipeline function uses the with span: pattern correctly, but this function does not.

In the span_streaming=True branch (lines 66-88), the test parameters expected_first_ten and send_default_pii are passed to the test but never verified. The static path verifies these via redis.commands.first_ten assertions. This means PII filtering behavior is not tested in the streaming code path, reducing test coverage for a security-sensitive feature.

Also found at:

• tests/integrations/redis/cluster/test_redis_cluster.py:152-153

On line 293, the assertion assert "cache.hit" not in spans[1]["data"] checks spans[1] (the db.redis span from line 286), but should check spans[2] (the cache.put span being validated in the surrounding assertions on lines 288-294). This causes the test to validate the wrong span, making it less reliable for catching regressions in the cache.put functionality.

Also found at:

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

In _sentry_execute_command, spans are manually entered via __enter__() but if old_execute_command raises an exception, neither db_span.__exit__() nor cache_span.__exit__() are called. This leaves spans in an incomplete state (never finished) and leaks span context on the scope. The spans should be wrapped in try/finally to ensure proper cleanup.

Also found at:

• sentry_sdk/integrations/redis/_sync_common.py:151-158

Line 330 checks spans[1]["data"] for the absence of cache.hit, but the surrounding assertions (lines 325-329 and 331) all operate on spans[2] which is the cache.put span. spans[1] is a db.redis span (as confirmed by line 323). This test bug means the assertion passes by accident since db.redis spans don't have cache.hit, rather than verifying the intended behavior that cache.put spans should not have cache.hit.

Also found at:

• tests/integrations/redis/test_redis_cache_module_async.py:293