You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MemoryFileStore keys every topic file by _slugify_topic(topic), which strips everything that is not a to z or 0 to 9. The mapping is many to one: C ++ and C # both slug to c, node.js and node js both slug to node-js, and API and api collide too. write_topic then does an unconditional overwrite of the slug path, so writing a second topic that shares a slug with an existing one silently destroys the first topic's memories.
Reproduced on current main: write topic C ++ with the memory Modern C ++ prefers smart pointers, then topic C # with C # 12 primary constructors. Afterwards get_topic("C ++") returns the C # memory, the C ++ memory is gone, and list_topics shows a single topic.
The same file family deliberately uses the injective _storage_key_segment derivation for owner ids, session ids, source ids, and scopes, precisely so two byte distinct values do not share a storage location. The topic filename is the one mapping left below that standard.
Expected Behavior
Distinct topics must never share a memory file. Writing C ++ and C # should persist two files whose contents survive, and get_topic by topic name should keep returning each topic's own memories.
Steps to Reproduce
Create a MemoryFileStore and write two topics whose names share a slug.
Read the first topic back.
Minimal Reproduction
store.write_topic(session, MemoryTopicRecord(topic="C++", summary="cpp", memories=["smart pointers"], updated_at=...), source_id="memory")
store.write_topic(session, MemoryTopicRecord(topic="C#", summary="csharp", memories=["primary constructors"], updated_at=...), source_id="memory")
store.get_topic(session, source_id="memory", topic="C++").memories# returns the C# memory on main
This appears to be the same topic-identity defect tracked in #9205: distinct topic names map through _slugify_topic() to the same persisted file, so writes, reads, or deletes can affect another topic. The punctuation/case examples here and the non-English/accented examples there should be covered by one agreed scope and regression set.
Could the reporters and contributors reconcile/combine the two reports and coordinate the implementation in #9724 with westey (@westey-m) and the existing discussion on #9205? Please carry over the legacy-file ownership, lookup, and migration concerns already raised there. This is a request to coordinate the issues and proposed fix, not approval of a filename/migration strategy or permission to bypass the existing shared-memory design hold. Both issues remain open for now.
Activity
[-]Python: MemoryFileStore topic slug collisions silently overwrite another topic's memories[/-][+].NET: Python: MemoryFileStore topic slug collisions silently overwrite another topic's memories[/+]eavanvalkenburg commentedon Nov 2, 2026
This appears to be the same topic-identity defect tracked in #9205: distinct topic names map through
_slugify_topic()to the same persisted file, so writes, reads, or deletes can affect another topic. The punctuation/case examples here and the non-English/accented examples there should be covered by one agreed scope and regression set.Could the reporters and contributors reconcile/combine the two reports and coordinate the implementation in #9724 with westey (@westey-m) and the existing discussion on #9205? Please carry over the legacy-file ownership, lookup, and migration concerns already raised there. This is a request to coordinate the issues and proposed fix, not approval of a filename/migration strategy or permission to bypass the existing shared-memory design hold. Both issues remain open for now.