Session lease recovery from dead or detached owners
NousResearch/hermes-agent · cluster 104691
Data as of
Nothing open on GitHub. Fix merged in #104857. Check it covers your case.
The short answer
- Known?
- Yes. 7 related items grouped here, 1 issue already closed.
- Fix event
- A fix was merged to main in PR #104857. Check it covers your case. No release data is tracked.
- Tracker
- The maintainers' tracker marks this
unresolved. That is separate from the fix event. - Still open
- Nothing open on GitHub.
Multiple fixes and a related bug report addressing scenarios where sessions become permanently locked by stale or orphaned ownership leases after a runtime, lane, or desktop session tears down. The work focuses on reclaiming those leases so sessions can be reused without manual intervention.
Open issues0
Open PRs0
Fixes on record
-
#104857 fix(desktop): recover abandoned sessions without breaking live ownership
files:
evals/desktop_bug_campaign/leases_live.py,tests/tui_gateway/test_protocol.py,tui_gateway/session_reaper.py,website/docs/user-guide/configuration.md -
#113947 fix(tui_gateway): a chat restored under a new runtime no longer stays SESSION_NOT_OWNED behind its own detached lease (#104691)
files:
tests/tui_gateway/test_cross_process_orphan_ownership.py,tui_gateway/session_lifecycle.py
4 PRs closed without merging
From the close comments: superseded by another PR 2 · done elsewhere 1 · duplicate 1
-
#104704 fix(sessions): recover detached desktop chats from permanent owner lock · superseded by another PR →
18955c3,#104857 -
#104737 fix(sessions): reclaim resident leases from dead lanes (carry-forward #104710) · duplicate →
#104710,#104691 -
#105510 fix(sessions): reclaim resident leases from dead lanes · done elsewhere →
#104691,#104710,#104737,#104857 -
#105540 fix(sessions): reclaim resident leases from dead lanes · superseded by another PR →
18955c3,#104710,#104857,#113947,#104737,#105510,#105540,#104691
Closed issues · 1
- Closed#104691[Bug]: zombie session lease on a torn-down lane locks a session permanently ("already has a live owner")
How this cluster was grouped
-
Link evidence (
structural links throughout): every member is connected by structural evidence: shared changed files, or a closing/superseded reference. -
Pairwise link density
0.29: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36.1.00means every pair is linked.
Pick up a Lab task
Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.
Open the Lab