#732 accepted a measured ceiling on live_session_may_be_ours: a listing that omits a live session reads as "no session", so delete, archive and clean proceed and remove a run directory the session still depends on. The ceiling is now written into the guard's docstring and into docs/FEATURES.md, with two ways to meet it.
One of those two is upstream's, and it is fixable:
has-session deletes a live server's .port file when its 500 ms connect does not land, so ls exits 0 without that session until the server's registry maintenance re-writes it. Filed as psmux/psmux#622, with a measurement on installed psmux 3.3.8 (66cf613) under an isolated PSMUX_DATA_DIR, a tmux 3.4 comparison showing tmux blocks rather than reaping and never mutates registry state from a read-only predicate, and a source read confirming the site is unchanged between v3.3.8 and master 80362fa. The four sibling reap sites in that binary already gate on ConnectionRefused — the defect is that this one does not.
The other way is ours and does not go away: a process whose PATH lacks the multiplexer binary reads every session as absent, because the binary is per-process while the server is not.
What to do when it is fixed upstream
This retirement is documentation, not code — which is exactly why it needs an issue. There is no workaround to delete and no version gate to flip: #732 established that no gate is possible, because the reap produces a successful query with an incomplete answer (exit 0, empty, nothing on stderr) and there is no detectable condition to branch on. Nothing in the codebase will fail or warn when this stops being true.
So when a psmux release carries the psmux#622 fix and _LAST_UNSUPPORTED moves to that release or later:
Until then the wording is correct and should stay.
Why this is filed rather than left to a future reader: a documented limit that has quietly stopped being true is worse than an undocumented one — it is confidently wrong, and an operator meeting it will design around a window that no longer exists. The 3.3.8 adoption family exists because the same thing happened to a set of workarounds whose upstream premises had all been fixed; this is the same trap one layer down, in prose instead of in code.
Sibling of #733, which retires the #537 control-session suffix once psmux/psmux#599 lands. Refs #732, #660
#732 accepted a measured ceiling on
live_session_may_be_ours: a listing that omits a live session reads as "no session", sodelete,archiveandcleanproceed and remove a run directory the session still depends on. The ceiling is now written into the guard's docstring and intodocs/FEATURES.md, with two ways to meet it.One of those two is upstream's, and it is fixable:
has-sessiondeletes a live server's.portfile when its 500 ms connect does not land, solsexits 0 without that session until the server's registry maintenance re-writes it. Filed as psmux/psmux#622, with a measurement on installedpsmux 3.3.8 (66cf613)under an isolatedPSMUX_DATA_DIR, a tmux 3.4 comparison showing tmux blocks rather than reaping and never mutates registry state from a read-only predicate, and a source read confirming the site is unchanged betweenv3.3.8and master80362fa. The four sibling reap sites in that binary already gate onConnectionRefused— the defect is that this one does not.The other way is ours and does not go away: a process whose PATH lacks the multiplexer binary reads every session as absent, because the binary is per-process while the server is not.
What to do when it is fixed upstream
This retirement is documentation, not code — which is exactly why it needs an issue. There is no workaround to delete and no version gate to flip: #732 established that no gate is possible, because the reap produces a successful query with an incomplete answer (exit 0, empty, nothing on stderr) and there is no detectable condition to branch on. Nothing in the codebase will fail or warn when this stops being true.
So when a psmux release carries the psmux#622 fix and
_LAST_UNSUPPORTEDmoves to that release or later:live_session_may_be_ours(src/bmad_loop/runs.py) and indocs/FEATURES.mdto the PATH case alone. Both currently describe the reap as a live limit.Until then the wording is correct and should stay.
Why this is filed rather than left to a future reader: a documented limit that has quietly stopped being true is worse than an undocumented one — it is confidently wrong, and an operator meeting it will design around a window that no longer exists. The 3.3.8 adoption family exists because the same thing happened to a set of workarounds whose upstream premises had all been fixed; this is the same trap one layer down, in prose instead of in code.
Sibling of #733, which retires the #537 control-session suffix once psmux/psmux#599 lands. Refs #732, #660