Python: fix(redis): scope RedisHistoryProvider keys by source_id

[Yufeng He (he-yufeng)]

Motivation & Context

Two RedisHistoryProvider instances with different source_ids that share a session id used to read and write the same Redis list, so one provider's history leaked into another's model context and either side's clear() wiped both. This scopes the Redis key by source_id and keeps pre-scoping data readable.

Successor of #7494: moonbox3 closed that one until every review thread was addressed, and GitHub will not reopen it now that the branch has moved, so this continues from there. All four threads are answered and resolved on #7494, and the rework they prompted is in here.

Description & Review Guide

• What are the major changes? The key is built from length-prefixed (prefix, source_id, session) parts so opaque ids cannot collide the join. Reads merge the legacy unscoped list in place (legacy entries first, since new writes only land on the scoped key). clear() deletes only the scoped key. Compared to Python: fix(redis): scope RedisHistoryProvider keys by source_id #7494 the lazy renamenx migration is gone: nothing moves on read, so a shared legacy list is never claimed by one reader, rolling upgrades cannot fork history, no Redis error is swallowed around a move, and one source's clear() cannot erase another source's pre-upgrade history.
• What is the impact of these changes? Scoped sessions behave exactly as before. Sessions written before scoping stay readable until an operator removes the old key deliberately.
• What do you want reviewers to focus on? The ordering claim (legacy strictly precedes scoped) and the mixed-version read path.

Related Issue

Fixes #7471

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Pull request overview

Scopes Redis history keys by source_id while preserving access to legacy session data.

Changes:

• Adds collision-safe, length-prefixed scoped keys.
• Merges legacy and scoped histories.
• Updates isolation, compatibility, trimming, and clearing tests.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
python/packages/redis/agent_framework_redis/_history_provider.py	Implements scoped keys and legacy reads.
python/packages/redis/tests/test_providers.py	Tests key isolation and compatibility behavior.

Suppressed comments (3)

python/packages/redis/agent_framework_redis/_history_provider.py:225

• Because get_messages() always merges the legacy list, deleting only the scoped key does not fulfill clear()'s contract: a subsequent read immediately returns the legacy messages again. This also conflicts with the constructor documentation that directs callers to clear() to remove stored history. Keep the shared legacy list intact, but add source-scoped state (for example, a cutoff/tombstone) that makes this provider stop reading legacy data after it is cleared.

        Only the scoped key is deleted. A pre-scoping legacy list belongs to
        whichever sources shared it, so it is left for an explicit admin
        cleanup rather than being removed by one source's clear().

python/packages/redis/agent_framework_redis/_history_provider.py:159

• Merging both complete lists bypasses max_messages. For example, after upgrading a provider configured with max_messages=10, ten retained legacy entries plus ten scoped entries are all returned and retained as a 20-message session, even though the public option promises a per-session maximum. Apply the configured limit to the merged view (while preserving the documented zero behavior), or define a migration policy that retires legacy entries without modifying another source's data.

            legacy_messages: list[str] = await self._redis_client.lrange(legacy_key, 0, -1)  # type: ignore[misc]
            if legacy_messages:
                redis_messages = [*legacy_messages, *redis_messages]

python/packages/redis/agent_framework_redis/_history_provider.py:157

• This adds a second sequential Redis round trip to every history read, including fresh deployments where the legacy key never existed, and the cost remains indefinitely because there is no migration cutoff. Fetch both lists in one non-transactional pipeline or make legacy fallback an explicit/temporary compatibility mode so normal scoped reads retain their previous latency.

            legacy_messages: list[str] = await self._redis_client.lrange(legacy_key, 0, -1)  # type: ignore[misc]

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Yufeng He (he-yufeng)]

Rebased onto current main in 5509aad. The merge combined upstream's _redis_result return-type hardening with the scoped-key read path: both lrange calls (scoped and legacy) now go through the _redis_result(cast("Any", ...)) idiom, and upstream's new tests are kept alongside the legacy-merge ones. Two upstream tests needed key-aware mocks since the read path now queries the scoped key first and the legacy key second. The full redis package suite passes (51 tests) and ruff is clean on both files.