Repository navigation
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
RedisLTMBackendcreates one RediSearch index per user, namedveadk-ltm/{index}/{user_id}, withprefixset to the same string andkey_separator="_". RediSearch indexes every key that starts with the prefix, so the index of useru1(prefixveadk-ltm/app/u1) also indexes the keys of useru10(veadk-ltm/app/u10_<id>),u100,u1abc, and so on.search_memory(user_id="u1", ...)then returns other users' memories.Reproduction (real Redis Stack 7.4,
MockEmbedding)On main the
u1query logsFound 1 results ... ['veadk-ltm/repro/u10_5ecec7c3-...'].Fix
{index}_with an emptykey_separator. Stored keys keep the exact{index}_{id}format, so existing memories are still found.RedisVectorStoredoesn't redefine an existing index). Before creating the vector store, the backend readsFT.INFO. If the prefix is stale, it drops only the index definition (FT.DROPINDEXwithoutDD, so no data is deleted), and the index is recreated with the correct prefix. RediSearch then re-indexes the existing keys.Re-running the reproduction against the same Redis after the fix:
u1no longer seesu10's memory,u10still finds its own old memories, andFT.INFO veadk-ltm/repro/u1showsprefixes: ['veadk-ltm/repro/u1_'].Verification
tests/memory/long_term_memory_backends/test_redis_ltm_backend.pyuses fake Redis and vector store objects, so it needs no server. 2 of the 4 tests fail on main (prefix overlap, stale index not redefined) and all 4 pass with the fix.uv run --extra dev pre-commit run --all-files: pass.uv run --extra dev pytest -n 4 -m "not codex_smoke and not piagent_smoke": 8056 passed. The same 24 failures and 2 collection errors (Codex runtime / self-host sandbox tests that need local tooling) occur on unmodified main in this environment.Impact
No public API change. On first use after upgrading, each existing user index is redefined once (data kept) and re-indexed by Redis in the background.
This PR was prepared with an AI coding agent; I authorized the submission.