fix(C20): align hermes_plugin _triple_store cache with active memory

[kohai-ut]

Summary

• hermes_plugin/__init__.py held two module-level singletons — _memory_instance (the Mnemosyne wrapper) and _triple_store (the TripleStore that backs the knowledge-graph triple tools) — that should always point at the same SQLite database. The session-change invalidation logic existed for _memory_instance but was never extended to _triple_store. After a session or bank switch, memory writes routed to the new DB while triple writes silently kept going to the old DB.
• Fix resets _triple_store = None whenever _memory_instance is rebound, plus a defensive Path(db_path) mismatch check in _get_triples() as cheap insurance, plus a build-before-assign in _get_memory() so a partial constructor failure can't poison _current_session_id and leave the cache in an inconsistent state.
• Three regression tests: cache-invalidation contract, end-to-end via the public mnemosyne_triple_add tool, and an env-change scenario that locks in env-honoring behavior so an earlier over-engineered version of this fix can't silently come back.

The bug in detail

hermes_plugin/__init__.py exposes the Mnemosyne knowledge graph through three module-level globals:

_memory_instance = None        # the active Mnemosyne wrapper
_current_session_id = None     # the session_id _memory_instance was built with
_triple_store = None           # the TripleStore that writes/reads the triples table

_get_memory(session_id) rebinds _memory_instance whenever the requested session_id differs from _current_session_id:

if _memory_instance is None or _current_session_id != session_id:
    _current_session_id = session_id
    _memory_instance = Mnemosyne(session_id=session_id, ...)

_get_triples() was a one-shot lazy initializer:

def _get_triples():
    global _triple_store
    if _triple_store is None:
        mem = _get_memory()
        _triple_store = TripleStore(db_path=mem.db_path)
    return _triple_store

The first call captures mem.db_path into the cached TripleStore and the cache is never invalidated. Every later _get_triples() returns the same store regardless of where memory has moved to.

What the user actually sees go wrong

Take a long-running Hermes plugin process that handles a session in the default bank, then is asked to switch to a project-specific bank for a different conversation context:

1. Session "default", first triple op:
   _get_memory("default")      → memory at ~/.hermes/.../mnemosyne.db
   mnemosyne_triple_add(...)   → _get_triples() initializes TripleStore at the
                                 default DB, writes triple ✓
   mnemosyne_remember(...)     → writes to default DB ✓

2. Hermes switches to bank "project_a":
   _get_memory("hermes_project_a")  → memory rebinds to
                                       ~/.hermes/banks/project_a/mnemosyne.db
   mnemosyne_remember(...)          → writes to project_a's DB ✓
   mnemosyne_triple_add(...)        → _get_triples() returns the CACHED store
                                       still pointing at the default DB ✗
                                     → triple goes to ~/.hermes/.../mnemosyne.db,
                                       NOT project_a's DB

A triple written through the mnemosyne_triple_add tool while in project_a ends up in the default bank's database. The user sees no error. mnemosyne_triple_query against project_a returns nothing for that triple. The default bank quietly accumulates project_a's data for the rest of the process lifetime.

The damage compounds over a long-running plugin process: every session/bank switch widens the gap between where memory thinks it is and where triples are actually being written. The data lives, but in the wrong place. Restoring it after the fact would require manual SQL surgery.

Why it slipped through

The cache-invalidation logic was added when _memory_instance was first introduced as a session-aware singleton. _triple_store was added later but the invalidation pattern wasn't extended. There was no test for "switch session, write triple, verify destination" — most tests instantiate Mnemosyne directly with an explicit db_path and never exercise the plugin singletons. tests/conftest.py resets all three globals between tests as a hygiene fixture, which actively masks the bug in CI: it tests the cold-start path, never the session-switch path.

This is the same anti-pattern as C26 (internals tested, public-surface wrapper untested). The plugin singleton state has practically no direct test coverage. PR adds the first.

The fix

Two small changes in hermes_plugin/__init__.py:

_get_memory() — reset the cache on rebuild + harden against partial init failures:

if _memory_instance is None or _current_session_id != session_id:
    # Build into a local first so a Mnemosyne(...) failure (DB locked,
    # embedding init error, etc.) does not poison global state — leaving
    # _current_session_id ahead of _memory_instance would make the next
    # call return the stale instance silently.
    new_memory = Mnemosyne(session_id=session_id, ...)
    _memory_instance = new_memory
    _current_session_id = session_id
    # Triple store cache must follow memory; reset so the next
    # _get_triples() rebuilds with the new instance's db_path.
    _triple_store = None

The build-before-assign is independent of the C20 cache fix but addresses a related fragility flagged in cross-model review: previously, _current_session_id advanced before the new Mnemosyne(...) finished constructing. If construction raised mid-way (locked DB, embedding model fail, etc.), _current_session_id would already point at the new session while _memory_instance stayed on the prior one, and _triple_store = None never executed. The next call would see session-match and return the stale memory plus stale triple store — silently wrong. Building into a local variable first means the globals only update if the constructor returns successfully.

_get_triples() — defensive check, env-honoring:

def _get_triples():
    global _triple_store
    mem = _get_memory()
    if _triple_store is None or Path(_triple_store.db_path) != Path(mem.db_path):
        _triple_store = TripleStore(db_path=mem.db_path)
    return _triple_store

The function still calls _get_memory() (which reads HERMES_SESSION_ID env when called with no arguments), so an env-change between calls still triggers the same session-rebind logic for triple operations as for memory operations. The added Path() mismatch check is cheap insurance against any future code path that might mutate mem.db_path without going through _get_memory() (none today, but defensive).

Options considered, and what got reverted

The first commit on this branch took a more aggressive approach: have _get_triples() read _memory_instance directly to avoid calling _get_memory() at all. That came from a debugging detour where I chased a test that called _get_memory("session_a") without setting HERMES_SESSION_ID env to match — the internal _get_memory() no-arg call defaulted to env, didn't match the explicit session, and rebound away.

Both Claude and Codex adversarial reviewers caught that the bypass introduced a real regression: if HERMES_SESSION_ID env changes after a session has been bound but before any explicit _get_memory(new_session) call, a triple-only operation would still route to the old session's DB. The bypass had removed the env-honoring path that the original code (and Hermes's actual session-change flow) relied on.

The second commit reverts the bypass and updates the test to set env consistently with the explicit session — matching how Hermes coordinates env and explicit calls in production. A new regression test (test_get_triples_honors_env_change_without_explicit_memory_call) explicitly locks in the env-honoring behavior so a future regression of this design choice would surface in CI.

Tests

tests/test_hermes_plugin_session.py — 3 regression tests:

1. test_get_triples_follows_active_memory_after_session_switch — monkeypatches Mnemosyne so each session_id resolves to a distinct db_path. Asserts that after a session change, _get_triples() returns a TripleStore aligned with the new memory's db_path. RED before the fix, GREEN after.

2. test_triple_writes_route_to_new_db_after_session_switch — end-to-end through the public mnemosyne_triple_add tool. Writes one triple in session_a, switches to session_b, writes another. Reads each DB directly (bypassing the plugin cache) and asserts each triple landed in its correct DB and did not leak across.

3. test_get_triples_honors_env_change_without_explicit_memory_call — locks in env-honoring. Sets env to session_a, calls _get_memory(session_a), captures _get_triples() at db_a. Then changes env to session_b WITHOUT calling _get_memory(session_b). Asserts the next _get_triples() call routes to db_b. Would fail under the bypass design from the first commit.

Deferred

Both adversarial reviewers flagged pre-existing concerns that are out of scope for this fix:

• TOCTOU race on the module globals. The check-then-set pattern (if _memory_instance is None or _current_session_id != session_id: _memory_instance = ...) is racy if multiple threads call _get_memory() concurrently. The GIL mitigates the worst cases but doesn't eliminate them. Pre-existing in the singleton design.
• TripleStore.conn is shared across threads with check_same_thread=False. SQLite-Python documents that check_same_thread=False does not provide concurrency safety; the caller is expected to serialize. Pre-existing design choice; out of scope here.

If the plugin is single-threaded in practice (Hermes's typical deployment), neither hits in production. They're worth a follow-up if a future deployment introduces concurrency.

Test plan

• uv run pytest tests/test_hermes_plugin_session.py -q (3 passed locally)
• uv run pytest -q --ignore=tests/test_local_llm.py --ignore=tests/test_llm_backends.py (445 passed locally)
• Manual: in a long-running plugin process, switch banks via the on_session_start hook, write a triple via mnemosyne_triple_add, verify it lands in the new bank's DB (not the old one).
• Manual: change HERMES_SESSION_ID env mid-process, call a triple tool without first calling a memory tool, verify the triple lands in the new session's DB.

Verification

```
tests/test_hermes_plugin_session.py: 3 passed (new file, all RED before fix)
full suite excluding LLM-dependent tests: 445 passed
```

Note on the unrelated test_hermes_llm_adapter.py failures: those manifest only when test_plugins.py runs first (state leakage in the PluginManager registry, unrelated to this fix). Alphabetical pytest discovery puts test_hermes_llm_adapter before test_plugins, so the full suite passes. Pre-existing test isolation issue, not introduced by this branch.