A reclaimed session tells the client instead of vanishing - #75836
Merged
Conversation
The idle-TTL reaper, the LRU cap, and the WS-orphan reap tear down a live session without the client asking. Nothing was pushed, so a client kept a runtime id the backend had already forgotten and only found out by failing a later prompt. Broadcast session.reclaimed with the runtime id and the reason; client-initiated closes stay silent.
Evict the runtime the backend just reclaimed instead of waiting for a resume to 404, and refresh the lists whose ended_at moved. The stored row is untouched, so reopening resumes from the DB.
OutThisLife
enabled auto-merge
August 1, 2026 04:06
Contributor
૮ >ﻌ< ა ci reviewran on 9824e95 ℹ️ InfoDesktop E2E visual evidence · View test artifacts · View job2 visual diffs. inline evidence is publishing... |
randlee
pushed a commit
to randlee/hermes-agent
that referenced
this pull request
Aug 11, 2026
…ap-notify A reclaimed session tells the client instead of vanishing
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three backend paths tear down a live session without the client asking: the idle-TTL reaper, the
max_live_sessionsLRU cap, and the WS-orphan reap (on by default, 20s after a transport detaches). None of them told anyone._teardown_sessionpushed no event, andws_orphan_reap/lru_evict/idle_timeoutappeared nowhere in the desktop or TUI clients.So a client kept holding a runtime id the backend had already forgotten, and only discovered it by failing a later prompt against a session that no longer existed. Reported as sessions "suddenly lost in the backend" when running several at once — the reclaim is intentional, the silence is what makes it read as data loss.
The backend now broadcasts
session.reclaimedwith the runtime id, the stored id, and the reason. It broadcasts rather than targets the session, because the reap paths run on background timer threads with no contextvar binding and the WS-orphan case has by definition lost its own transport — a targeted emit would bottom out on stdio and never reach the peer that owns the session. Client-initiated closes (tui_closeand friends) stay silent; the client asked for those and already knows.The desktop drops the cached state for that runtime instead of waiting for a resume to 404, reusing the same
dropSessionStateprimitive the existing dead-tile path already calls, and refreshes the lists whoseended_atmoved. The stored row is untouched, so the conversation stays in the sidebar and reopening it resumes from the DB.No lifecycle change: the eviction guards are as they were, mid-turn / awaiting-approval / still-building sessions remain exempt, and the 20s orphan grace from #38591 is unchanged. This only makes an existing reclaim visible.