Supervised launches incorrectly re-running update completion tail
NousResearch/hermes-agent · cluster 123340
Data as of
Nothing open on GitHub. Fix merged in #127745. 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 #127745. Check it covers your case. No release data is tracked.
- Tracker
- The maintainers' tracker marks this
resolved, deciding PR #127745. That is separate from the fix event. - Still open
- Nothing open on GitHub.
These issues and fixes address a bug where supervised or gateway launches repeatedly re-execute the update completion tail, causing the installs directory to grow unboundedly and potentially exhaust disk space. The fixes prevent the completion tail from running during supervised starts under various conditions.
Open issues0
Open PRs0
Fixes on record
-
#127745 Supervised gateway starts no longer re-run an unfinished update tail until the disk fills (#123340, salvage #123364)
files:
hermes_cli/venv_sync.py,tests/hermes_cli/test_update_launch_completion.py -
#131001 Finished updates stay finished: no same-commit re-run on launch, Windows exit 124 after completion is success (salvage #123863, #127198)
files:
hermes_cli/post_update.py,hermes_cli/source_stamp.py,hermes_cli/venv_sync.py,scripts/desktop-update/windows.ps1,tests/hermes_cli/test_update_launch_completion.py,tests/scripts/desktop_update/test_desktop_update_windows_python_handoff.py
3 PRs closed without merging
From the close comments: done elsewhere 2 · merged via another change 1
-
#123364 fix(update): keep supervised launches off the pending completion tail · merged via another change →
#127745 -
#123863 fix(update): skip source-update completion when the stamp names HEAD · done elsewhere →
#131001 -
#124785 fix(cli): never run the update completion tail from a supervised launch · done elsewhere →
#123340,#127745,#123364
Closed issues · 1
- Closed#123340systemd gateway re-runs source-completion tail on every start; installs/<hash>/environments grows to tens of GB / ENOSPC
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