`delete_all` removes DB rows but not the in-process hsg query cache — deleted memories remain retrievable for the process lifetime

[gnanirahulnutakki]

Package: openmemory-py (CaviraOSS OpenMemory), local SQLite + hierarchical semantic graph

What happens

1. add(...) some memories for a user, then search(...) — results returned (correct).
2. delete_all(user_id=...) — clears the DB rows (memories, vectors, waypoints, verified empty in SQLite).
3. search(...) for the same user still returns the deleted memories, served from the in-process query cache in openmemory/memory/hsg.py (module-level cache dict). They remain retrievable until the process restarts (or the cache is cleared manually via hsg.cache.clear()).

Impact
Deletion-durability / privacy: delete_all reports success and empties the database, but a long-lived process keeps answering with the deleted content. Anything relying on deletion for privacy/compliance is silently violated within a single process lifetime.

Suggested fix
Invalidate the hsg query cache (at least the affected user_id's entries) inside delete_all / del_mem_by_user, so deletion is reflected immediately without a restart.

Note (unrelated, minor): the npm name openmemory belongs to an unrelated Mem0 MCP wrapper; CaviraOSS ships openmemory-js / openmemory-py. A disambiguation note in the README would help adopters.

— Reported by ArdurAI, from independent benchmarking of open-source agent-memory tools.