In sentry_patched_execute_command, the db_span and cache_span are manually entered via __enter__() but if old_execute_command() raises an exception, the __exit__() calls on lines 152 and 156 are never reached. This causes spans to leak (not be properly closed), the error status to not be recorded on the span, and potentially corrupted scope state for StreamedSpan which tracks _previous_span_on_scope.

The test_redis_pipeline function is parametrized with is_transaction, send_default_pii, and expected_first_ten, but when span_streaming=True, these parameters have no effect on the assertions. The streaming branch only asserts on span names, op, origin, and db.system.name, without verifying that different transaction/pii/command formatting behaviors work correctly. This means the streaming path runs multiple parameter combinations but doesn't actually test differentiated behavior, creating a false sense of test coverage.

Also found at:

• sentry_sdk/integrations/redis/modules/queries.py:54

Line 293 checks spans[1]["data"] for the absence of cache.hit, but the surrounding context is asserting properties of spans[2] (the cache.put span). This appears to be a copy-paste error where the index should be spans[2]["data"] to check that the cache.put operation doesn't have a cache.hit attribute. The test will pass incorrectly if spans[1] (db.redis) happens to not have cache.hit, even if spans[2] has it erroneously.

Also found at:

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

The code manually enters spans using __enter__() (lines 126, 145) and exits them using __exit__(None, None, None) (lines 152, 156), but if old_execute_command() (line 150) raises an exception, the __exit__ calls are never reached. This causes spans to remain open/unfinished, corrupts the scope's current span, and fails to record the error status on the spans.

The test asserts attrs["db.system.name"] == "redis-py" but the implementation in sentry_sdk/integrations/redis/modules/queries.py:54 sets span.set_attribute("db.system.name", "redis"). This test will fail at runtime. The value "redis-py" is actually used for DB_DRIVER_NAME, not db.system.name.

Line 330 checks spans[1]["data"] for absence of cache.hit, but spans[1] is a db.redis span (confirmed at line 323). The assertion should check spans[2] which is the cache.put span (confirmed at line 325). This causes the test to always pass since db.redis spans never have cache.hit, masking potential bugs where cache.put spans incorrectly include this attribute.

Also found at:

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