Summary
praisonaiagents/memory/storage.py defines StorageMixin, a base of the Memory class. Every one of its 10 methods is re-defined directly in the Memory class body in memory/memory.py, so by Python's MRO the mixin versions are never reached — the entire mixin is unreachable dead code (a stale second copy of the STM/LTM/chroma/mongodb storage logic). It can be removed without any behaviour change.
Current behaviour
class Memory(StorageMixin, SearchMixin, MemoryCoreMixin) — memory/memory.py:39; mixin imported at memory/memory.py:13.StorageMixin (memory/storage.py) defines exactly 10 methods: _get_stm_conn (21), _get_ltm_conn (34), _init_stm (47), _init_ltm (62), _init_chroma (77), _init_mongodb (116), _create_mongodb_indexes (153), _create_vector_search_indexes (168), reset_short_term (177), reset_long_term (206).- All 10 are re-defined directly in the
Memory class body in memory.py (verified: each name has exactly one def in the class body). Since Memory is the most-derived class, its own definitions win on every call; the StorageMixin copies are unreachable.
- The two copies have already diverged (e.g.
storage.py _init_chroma defaults to rag_memory_db with short_term_memory/long_term_memory collections; the live memory.py:464 uses chroma_db + a single memory_store collection) — confirming the mixin is a stale fork, not a shared implementation.
StorageMixin is referenced nowhere else in the repository: only memory.py:13 (import) and memory.py:39 (base). No other subclass, no test imports it.
Contrast (do NOT touch): SearchMixin and MemoryCoreMixin are only partially overridden — methods like _search_vector_stm, _search_sqlite, and the store_* helpers remain live via those mixins. They are legitimate. Only StorageMixin is 100% shadowed.
Why it matters
Maintenance + correctness risk: ~233 lines of dead storage code that looks live and has already drifted from the real implementation. A future reader could "fix a bug" in StorageMixin and see no effect, or mistakenly wire it up and regress the chroma/mongodb collection layout.
Category
Dead code
Capability preserved
- All memory storage behaviour is unchanged — the live code in
Memory's class body (_init_chroma, _init_mongodb, reset_short_term, reset_long_term, etc.) is exactly what executes today and continues to execute.
- Short-term/long-term SQLite, ChromaDB, and MongoDB storage paths all remain fully functional.
- No public API affected (
StorageMixin is internal and unexported).
Proposed approach
Remove the dead StorageMixin base: drop it from the Memory(...) base list and the from .storage import StorageMixin import, then delete memory/storage.py. The class-body methods already provide every one of these methods. (Optionally, the reverse consolidation — keep one canonical copy in the mixin and delete the class-body duplicates — but the conservative, zero-risk move is to drop the unreachable mixin, since the class-body versions are the proven-live implementations.)
Resolution sketch
# Before — memory/memory.py
from .storage import StorageMixin
class Memory(StorageMixin, SearchMixin, MemoryCoreMixin):
def _init_chroma(self): ... # live (wins MRO)
# ...9 more methods that also shadow StorageMixin...
# After — StorageMixin removed; behaviour identical
class Memory(SearchMixin, MemoryCoreMixin):
def _init_chroma(self): ... # unchanged, still the live implementationSeverity
Low
Validation
- Verified all 10
StorageMixin method names are each defined once in Memory's class body in memory.py and therefore win MRO — the mixin methods are unreachable.
- Verified
StorageMixin has no references outside memory/memory.py (no other subclass, no test).
- Confirmed
SearchMixin/MemoryCoreMixin are only partially overridden and must be kept.
- No public/exported symbol removed; no behaviour change.
Keep unchanged
- The live storage methods in
Memory's class body in memory.py.
SearchMixin and MemoryCoreMixin (legitimately live via partial override).- File-based memory and all optional-dep lazy-loading in the memory module.
Summary
praisonaiagents/memory/storage.pydefinesStorageMixin, a base of theMemoryclass. Every one of its 10 methods is re-defined directly in theMemoryclass body inmemory/memory.py, so by Python's MRO the mixin versions are never reached — the entire mixin is unreachable dead code (a stale second copy of the STM/LTM/chroma/mongodb storage logic). It can be removed without any behaviour change.Current behaviour
class Memory(StorageMixin, SearchMixin, MemoryCoreMixin)—memory/memory.py:39; mixin imported atmemory/memory.py:13.StorageMixin(memory/storage.py) defines exactly 10 methods:_get_stm_conn(21),_get_ltm_conn(34),_init_stm(47),_init_ltm(62),_init_chroma(77),_init_mongodb(116),_create_mongodb_indexes(153),_create_vector_search_indexes(168),reset_short_term(177),reset_long_term(206).Memoryclass body inmemory.py(verified: each name has exactly onedefin the class body). SinceMemoryis the most-derived class, its own definitions win on every call; theStorageMixincopies are unreachable.storage.py_init_chromadefaults torag_memory_dbwithshort_term_memory/long_term_memorycollections; the livememory.py:464useschroma_db+ a singlememory_storecollection) — confirming the mixin is a stale fork, not a shared implementation.StorageMixinis referenced nowhere else in the repository: onlymemory.py:13(import) andmemory.py:39(base). No other subclass, no test imports it.Contrast (do NOT touch):
SearchMixinandMemoryCoreMixinare only partially overridden — methods like_search_vector_stm,_search_sqlite, and thestore_*helpers remain live via those mixins. They are legitimate. OnlyStorageMixinis 100% shadowed.Why it matters
Maintenance + correctness risk: ~233 lines of dead storage code that looks live and has already drifted from the real implementation. A future reader could "fix a bug" in
StorageMixinand see no effect, or mistakenly wire it up and regress the chroma/mongodb collection layout.Category
Dead code
Capability preserved
Memory's class body (_init_chroma,_init_mongodb,reset_short_term,reset_long_term, etc.) is exactly what executes today and continues to execute.StorageMixinis internal and unexported).Proposed approach
Remove the dead
StorageMixinbase: drop it from theMemory(...)base list and thefrom .storage import StorageMixinimport, then deletememory/storage.py. The class-body methods already provide every one of these methods. (Optionally, the reverse consolidation — keep one canonical copy in the mixin and delete the class-body duplicates — but the conservative, zero-risk move is to drop the unreachable mixin, since the class-body versions are the proven-live implementations.)Resolution sketch
Severity
Low
Validation
StorageMixinmethod names are each defined once inMemory's class body inmemory.pyand therefore win MRO — the mixin methods are unreachable.StorageMixinhas no references outsidememory/memory.py(no other subclass, no test).SearchMixin/MemoryCoreMixinare only partially overridden and must be kept.Keep unchanged
Memory's class body inmemory.py.SearchMixinandMemoryCoreMixin(legitimately live via partial override).