A refused session delete leaks an instance reference: the session stays pinned in that process and every later delete there is refused #1765

What happened

EpisodicMemoryManager.delete_episodic_session takes a reference on the cached instance before it checks whether the instance is in use, and does not release it when it refuses (packages/server/src/memmachine_server/episodic_memory/episodic_memory_manager.py, as of 82b6c6f58 main):

ref_count = await self._instance_cache.get_ref_count(session_key)  # line 301
instance = await self._instance_cache.get(session_key)             # line 302, takes a reference
if instance and ref_count > 0:
    raise SessionInUseError(session_key, ref_count)                # line 304, reference not released

MemoryInstanceCache.get increments the node's ref_count (episodic_memory/instance_lru_cache.py:132, :139). Every refused delete therefore leaves the count one higher than the number of requests holding the instance, so it never returns to zero. close_session reads the count and raises before it calls get (episodic_memory_manager.py:357-362) and does not leak.

Reproduced by calling the manager directly with one cached instance held by one request, at instance_cache_size 0 and at 100, with the same result:

Why it matters

One delete that overlaps a request on the same session leaves that process in a state only a restart clears.

• The instance is pinned. With instance_cache_size: 0 an instance is dropped only when its count reaches zero (instance_lru_cache.py:208). With a cache, LRU eviction and the lifetime check both skip a node whose count is positive (:180, :226). The instance is never closed.
• The process keeps serving the deleted session. Both open paths check the session's status only on a cache miss (episodic_memory_manager.py:142-156, :253-266), so every later request gets the pinned instance although the row is in Deleted status. Without the leak, at the default cache size the instance would be dropped when the overlapping requests finish, and the next open would raise SessionDeletedError. With it, the stuck project in Deleting a project that is in use returns 204 and then never completes: the deletion worker gives up on SessionInUseError, leaves a partial deletion, and only a restart retries #1577 keeps answering after its in-flight requests have finished.
• No retry in that process can succeed. A later delete is refused with nothing in flight, and each attempt takes another reference. Nothing retries within a process on main today, so this part is latent, but it rules out the first fix Deleting a project that is in use returns 204 and then never completes: the deletion worker gives up on SessionInUseError, leaves a partial deletion, and only a restart retries #1577 proposes (retry a refused delete with a backoff) until the leak is fixed.

Expected

A refused delete leaves the reference count as it found it: read the count and raise before calling get, as close_session does.

Notes

Found while reading the instance cache for #1571. The leak is reproduced at the manager; its effect on the open paths is read from the code, not run end to end. The defect goes away when the reference counts and the in-use check are removed (#1755, PR (e)); the fix above is independent of that and of the deletion queue (#1749).

🤖 Written by Claude Code (Claude Fable 5.1) on behalf of @edwinyyyu.