mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-06-27 11:22:03 +00:00
f7bf740640
resumeSession's warm-cache fast-path trusted the storedSessionId -> runtimeId -> ClientSessionState mapping without checking the cached state still BELONGS to the session being resumed. A pooled profile backend that gets idle-reaped and respawned (pruneSecondaryGateways) re-mints runtime ids, so a recycled id can resolve to a live-but-DIFFERENT session's cache entry. The only existing guard was a session.usage 404 -- that catches a fully-dead runtime id, but a recycled id still 200s, so the fast-path happily painted the wrong transcript under the current route (open chat A, chat B loads). Fold the belongs-to check into a single takeWarmCache() helper used at BOTH cache reads -- the early transcript-keep decision and the fast-path itself -- so a cross-wired entry can't even briefly flash a stale transcript before the full resume repaints. On a mismatch the helper purges both stale map entries and reports a miss, falling through to a full resume that rebinds a correct runtime id. The full-resume path already guards its final paint with isCurrentResume(), so only the cached fast-path was missing the belongs-to check. Pre-existing bug from the initial desktop app (#20059); not introduced by the session-switch perf work (#49807), which left these lines untouched. Tests: two cases in use-session-actions.test.tsx driven through a harness that owns the two cache maps -- a cross-wired mapping is rejected + purged (the bug), and a correctly-wired cache still serves from memory with no needless refetch (no perf regression). Supersedes #50464 by @professorpalmer, reimplemented to also guard the early transcript-keep read (whole-class fix, not just the fast-path). Co-authored-by: professorpalmer <professorpalmer@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| bootstrap-installer | ||
| desktop | ||
| shared | ||