Severity: P1 — silent loss of user state. Verified live 2026-08-09 (server at main cbac09f).
Problem
Both handle stores silently bulk-evict the oldest entries when they hit their cap, and the caller only learns about it when a later call returns a generic "not found" — indistinguishable from a typo.
Live repro: a data handle created at the start of a session was gone after ~52 subsequent load_data_source calls:
inspect_data(data_handle="data_bdaec9a2")
-> {"success": false, "error": "Data handle 'data_bdaec9a2' not found"}
Root cause
- Estimator store —
HandleManager._cleanup_oldest (handles.py) deletes the 10 oldest outright when len >= max_handles (default 100).
- Data store —
Executor._cleanup_oldest_data (executor.py) deletes the oldest ~20% at once, emitting only a logger.debug — nothing reaches the caller.
Proposed fix
Distinguish evicted from never existed. Keep a tombstone set in both stores and return, e.g., "Data handle 'X' was evicted (limit N reached); reload the source." Better still: expose the limits + current usage via list_handles / list_available_data, and/or make eviction opt-in (raise at the cap). Never silently discard user state.
Re-verify
Create handles past the cap, then use the first one — the error must say evicted, not not found.
(Catalogued as BUG-08 in MCP_TEST_FINDINGS.md.)
Severity: P1 — silent loss of user state. Verified live 2026-08-09 (server at
maincbac09f).Problem
Both handle stores silently bulk-evict the oldest entries when they hit their cap, and the caller only learns about it when a later call returns a generic "not found" — indistinguishable from a typo.
Live repro: a data handle created at the start of a session was gone after ~52 subsequent
load_data_sourcecalls:Root cause
HandleManager._cleanup_oldest(handles.py) deletes the 10 oldest outright whenlen >= max_handles(default 100).Executor._cleanup_oldest_data(executor.py) deletes the oldest ~20% at once, emitting only alogger.debug— nothing reaches the caller.Proposed fix
Distinguish evicted from never existed. Keep a tombstone set in both stores and return, e.g.,
"Data handle 'X' was evicted (limit N reached); reload the source."Better still: expose the limits + current usage vialist_handles/list_available_data, and/or make eviction opt-in (raise at the cap). Never silently discard user state.Re-verify
Create handles past the cap, then use the first one — the error must say evicted, not not found.
(Catalogued as BUG-08 in
MCP_TEST_FINDINGS.md.)