Infinite FTS deferral blocked by permanent holders
NousResearch/hermes-agent · cluster 106393
Data as of
Nothing open on GitHub. Fix merged in #106591. Check it covers your case.
The short answer
- Known?
- Yes. 6 related items grouped here, 1 issue already closed.
- Fix event
- A fix was merged to main in PR #106591. 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.
These issues and fixes address a bug where stale full-text-search repair defers indefinitely when the blocking database holder is a permanent or supervised process. Work covers detection, diagnosis, holder identification, and retry logic to break the deadlock.
Open issues0
Open PRs0
Fixes on record
-
#106591 fix(state): futile stale-FTS deferral by a resident peer names the holder, fixes the remedy, and retries once it leaves (#106393, salvage #106410)
files:
hermes_cli/doctor_state.py,hermes_state_schema.py,tests/state/test_fts_runtime_rebuild.py -
#108130 state.db FTS damage no longer kills turns; doctor/repair/recover handle real incident shapes (#97794, #88587, #100227, #103840, #106667, #102240, #98050, #103647, #96591, #105887; salvage #97843 #88604 #56824 #91413 #102808 #103657 #106890 #103321)
files:
agent/turn_explainers.py,contributors/emails/[redacted:email],contributors/emails/[redacted:email],contributors/emails/[redacted:email],contributors/emails/[redacted:email],gateway/run_notifications.py,hermes_cli/console_engine.py,hermes_cli/doctor_state.py,hermes_cli/session_lost_and_found.py,hermes_cli/session_recovery.py,hermes_cli/sessions_cmd.py,hermes_cli/web_routers/_common.py,hermes_cli/web_routers/analytics.py,hermes_cli/web_server_sessions.py,hermes_constants.py,hermes_state_errors.py,hermes_state_fts.py,hermes_state_repair.py,hermes_state_schema.py,hermes_state_search.py(+12 more)
3 PRs closed without merging
From the close comments: done elsewhere 2 · merged via another change 1
-
#106410 fix(state): diagnose futile FTS deferral from a stable holder set · merged via another change →
060cd7f,#106591,#106393 -
#106559 fix(state): give the stale-FTS deferral an exit when the holder is permanent · done elsewhere →
#106393,#106591 -
#107981 fix(state): a permanent state.db holder no longer blocks the FTS rebuild forever (#106393, salvage #106559) · done elsewhere →
060cd7f,afff63c,#108130
Closed issues · 1
- Closed#106393[Bug]: stale-FTS repair defers forever when the blocking holder is a supervised service — every message write fails behind it
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.33: 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