fix(honcho): bound local session cache growth

[alex107ivanov]

What does this PR do?

Bounds the two unbounded-growth sources in the Honcho local session cache described in #71461: HonchoSession.messages (never trimmed) and HonchoSessionManager's four caches (_cache, _peers_cache untouched/_sessions_cache/_context_cache, no eviction path except an explicit /new). Together these cause monotonic RSS growth on any gateway with a long-lived channel that's never manually reset — distinct from the _agent_cache leak already fixed for #48287.

This is scoped to plugins/memory/honcho/session.py only — no changes to gateway/run.py or its watcher loop, since get_or_create() already re-fetches from Honcho (the durable source of truth) on a cache miss, so the fix can be entirely opportunistic/self-contained rather than needing new background-task wiring.

Related Issue

Fixes #71461

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• plugins/memory/honcho/session.py:
  • Added _SESSION_MESSAGE_RETENTION / _SESSION_IDLE_TTL_SECONDS / _SESSION_SWEEP_INTERVAL_SECONDS constants.
  • HonchoSessionManager._trim_synced_messages() (new, static): drops already-synced messages beyond the retention cap after a successful flush; never touches unsynced messages, even ones stuck mid-list from a failed sync.
  • HonchoSessionManager._sweep_idle_sessions_locked() / _maybe_sweep_idle_sessions() (new): idle-TTL eviction across _cache/_sessions_cache/_context_cache, rate-limited and triggered opportunistically from get_or_create() — no new background task needed. _peers_cache is deliberately left alone: it's keyed by distinct peer/user id, not by session, so its cardinality is bounded by user count rather than by uptime — it isn't part of this leak.
  • _flush_session() now calls _trim_synced_messages() right after a successful sync.
  • get_or_create() now calls _maybe_sweep_idle_sessions() on entry.
• tests/test_honcho_session_cache_bounds.py (new): 7 tests covering trim-caps-length, trim-never-drops-unsynced (including the stuck-mid-list case), trim-is-noop-under-cap, sweep-evicts-stale-across-all-caches, sweep-keeps-fresh, sweep-is-rate-limited, and a threading test guarding against the RLock reentrancy this design depends on (sweep is triggered from inside a method that also holds the lock).

How to Test

1. pytest tests/test_honcho_session_cache_bounds.py -v — all 7 new tests pass.
2. pytest tests/test_honcho_session_context.py tests/test_honcho_client_concurrency.py tests/test_honcho_startup_fail_open.py tests/test_honcho_client_config.py -v — confirms no regression in the existing 29 Honcho tests.
3. Manual repro of the original bug: create a HonchoSession, call add_message in a loop past _SESSION_MESSAGE_RETENTION, call _flush_session — len(session.messages) stays bounded instead of growing forever. Similarly, age a cached session's updated_at past _SESSION_IDLE_TTL_SECONDS and call _maybe_sweep_idle_sessions() — it's evicted.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(honcho):)
• I searched for existing PRs/issues first — see Honcho local session cache grows unbounded — no eviction path except explicit /new #71461 for the duplicate-check notes (related: [Bug]: Agent cache (_agent_cache) causes 50GB+ virtual memory leak in long-running gateway sessions #48287, [Bug]: Gateway memory grows ~5x over 20h on Linux — planned-restart masking leak, not fixing it #58817, feat: Honcho session pruning CLI (#33436) #33893, none of which cover this specific cache)
• My PR contains only changes related to this fix (no unrelated commits)
• I've run pytest tests/ -q and all tests pass — I ran the full Honcho-related test files (36 tests, all passing, listed above); the full repo-wide suite timed out collecting in my local environment (missing some optional dependency groups) rather than failing, so I couldn't confirm a full green run locally — deferring to CI for that. Happy to chase down the collection hang separately if it's not just an environment gap on my end.
• I've added tests for my changes
• I've tested on my platform — tested on macOS (Sonoma) only; no Linux/Windows-specific code paths touched, so I don't expect platform sensitivity here, but flagging per the checklist.

Documentation & Housekeeping

• N/A — no config keys added, no architecture/workflow changes, no tool schema changes.

Screenshots / Logs

$ pytest tests/test_honcho_session_cache_bounds.py -v
...
7 passed in 0.17s

$ pytest tests/test_honcho_session_context.py tests/test_honcho_client_concurrency.py \
    tests/test_honcho_startup_fail_open.py tests/test_honcho_client_config.py -q
29 passed in 5.40s

[alex107ivanov]

Rebased this PR onto upstream/main.

• upstream base: ba159d6fa9a12f29f85aaefab9a98020d9ca683a
• head: 48a207a3f8a1 -> d967329308f3
• validation: PYTHONPATH=$PWD /workspace/repos/hermes-agent/.venv/bin/python -m pytest tests/test_honcho_session_cache_bounds.py -q -> exit 0; ....... [100%] | 7 passed in 3.91s; git diff --check upstream/main...HEAD -> exit 0
• GitHub checks for new head: 0 workflow runs, 0 check runs observed immediately after push

[alex107ivanov]

Rebased this PR onto upstream/main.

• upstream base: 6cf572c9e5d88a33e0e51cfc5bcfe47f02682731
• head: d967329308f3 -> 5be5377155aa
• validation: PYTHONPATH=$PWD /workspace/repos/hermes-agent/.venv/bin/python -m pytest tests/test_honcho_session_cache_bounds.py -q -> exit 0; ....... [100%] | 7 passed in 1.33s; git diff --check upstream/main...HEAD -> exit 0
• GitHub checks for new head: 0 workflow runs, 0 check runs observed immediately after push

[teknium1]

Thanks for addressing a real current-main retention problem: add_message() still appends indefinitely and _flush_session() only marks entries synced (plugins/memory/honcho/session.py:45-54,421-458).

Problems

• The new cap is not a hard bound. _trim_synced_messages() stops at the first unsynced entry (plugins/memory/honcho/session.py:497 in this PR); the added test intentionally retains entries 10–299 after placing an unsynced message at index 10 (tests/test_honcho_session_cache_bounds.py:64-77). A persistent failed sync can therefore still grow the local list without limit.
• The sweep pops _context_cache under _cache_lock (plugins/memory/honcho/session.py:401 in this PR), but normal context-cache writes/pops are guarded by _prefetch_cache_lock on main (plugins/memory/honcho/session.py:708-718). Please use that lock for sweep removal and cover the concurrent prefetch case.

Suggested changes

• Specify a bounded failure-mode policy for unsynced messages, or narrow the claimed guarantee to successfully persisted history and test that contract.
• Synchronize context-cache eviction with the existing prefetch-cache lock.

Automated hermes-sweeper review.

[teknium1]

_context_cache is otherwise accessed under _prefetch_cache_lock (set_context_result() and pop_context_result() on main). Please acquire that lock for this removal as well; a background prefetch can otherwise race an idle sweep and repopulate stale context after eviction.

[teknium1]

This stops at the first unsynced item, so it does not enforce the advertised retention bound: the added test's unsynced item at index 10 leaves 290 entries. Please define and test the intended persistent-sync-failure policy, or narrow the bound claim to histories that have successfully flushed.