You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
cleanup/attach: two edge cases in reporting a pre-upgrade bmad-loop-ctl-<digest> session #915
#912 reports a pre-upgrade bmad-loop-ctl-<16 hex> control session that survived the rename in #900. Its last review round raised two narrow edge cases. They are recorded here rather than in another round on that PR, because neither is reachable with the backends and run ids bmad-loop itself produces today.
1. A persisted run whose id equals the old control-session digest
superseded_ctl_sessions matches the old control-session name through session_name_key(name) == old. Before the reserved-shape refusal (run_id_aliases_control_session), a caller could pass --run-id with a digest-shaped value. If such a run's id is exactly the old control-session digest for this registry, its agent session is bmad-loop-<id>, which the old formula also produced as the control-session name. Cleanup then publishes a kill-session command for it, and attach labels it as a control session, while that run may still be live.
Reaching this needs a run id that someone supplied by hand and that equals the 16-hex digest of this registry's root. bmad-loop never mints such an id. Possible fix: when a persisted run dir with that id exists, treat the role as ambiguous and name the session without a command.
2. legacy_registries() raising skips the primary-registry scan
In legacy_registry_leftovers, a MultiplexerError from legacy_registries() returns early with a legacy-discovery fault. The scan of the active (primary) registry for a superseded control session, which #912 adds after that call, then never runs, even when the primary registry can still be listed. The fault is visible, but the primary session and its kill command are omitted.
Only an out-of-tree backend can reach this. The in-tree tmux and psmux backends do not raise from legacy_registries(); the only in-tree raise on this path is backend selection failing, and then the primary registry cannot be listed either. Possible fix: run the primary scan independently of legacy discovery and keep both results.
Activity
fix(cleanup): withhold a pre-upgrade control session's command when a…