naps62/maestro
Archived
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

Dormant record advertises a worktree that was already removed #172

New Issue
Closed
opened 2026-09-04 08:36:59 +01:00 by naps62-yolo · 0 comments
naps62-yolo commented 2026-09-04 08:36:59 +01:00
Collaborator
Copy Link
Copy Source

A dormant record advertises a worktree that is already gone.

In mark_session_dead (crates/maestro-daemon/src/session.rs), when settle_worktree_on_exit removes a pristine tree, the map's record is cleared correctly — record.session.worktree, blocked_work, worktree_path, worktree_base_repo all go to None. But the local session clone, the one written to the sidecar and emitted as SessionUpdated, only gets blocked_work = None; its worktree still names the removed tree.

So the sidecar on disk keeps a worktree the daemon just deleted, and after a restart the dormant session registered from that sidecar advertises a branch and a path that no longer exist. Kill still works — in_the_way tolerates a missing path — so this is wrong information rather than a broken operation.

Fix is one line next to the existing session.blocked_work = None. Cover it with a test that exercises the natural-exit path with a pristine worktree and asserts on what the sidecar holds afterwards, not just the in-memory record — the in-memory copy was already correct, which is exactly why this survived.

The review also flagged the bridge-None guard in the activity pass as unreachable. Leave it: it is a defensive continue on an Option, and the alternative is an unwrap. Not part of this issue.

A dormant record advertises a worktree that is already gone. In `mark_session_dead` (`crates/maestro-daemon/src/session.rs`), when `settle_worktree_on_exit` removes a pristine tree, the map's record is cleared correctly — `record.session.worktree`, `blocked_work`, `worktree_path`, `worktree_base_repo` all go to `None`. But the local `session` clone, the one written to the sidecar and emitted as `SessionUpdated`, only gets `blocked_work = None`; its `worktree` still names the removed tree. So the sidecar on disk keeps a worktree the daemon just deleted, and after a restart the dormant session registered from that sidecar advertises a branch and a path that no longer exist. Kill still works — `in_the_way` tolerates a missing path — so this is wrong information rather than a broken operation. Fix is one line next to the existing `session.blocked_work = None`. Cover it with a test that exercises the natural-exit path with a pristine worktree and asserts on what the *sidecar* holds afterwards, not just the in-memory record — the in-memory copy was already correct, which is exactly why this survived. The review also flagged the bridge-`None` guard in the activity pass as unreachable. Leave it: it is a defensive `continue` on an `Option`, and the alternative is an unwrap. Not part of this issue.
naps62-yolo added this to the Reboot resilience milestone 2026-09-04 08:36:59 +01:00
naps62-yolo added the area/daemondifficulty/easytype/fix labels 2026-09-04 08:36:59 +01:00
naps62-yolo added a new dependency 2026-09-04 08:36:59 +01:00
#164 Detect host reboot via boot_id instead of probing tmux
naps62-yolo changed title from Fix dormant record worktree field and dead bridge guard to Dormant record advertises a worktree that was already removed 2026-09-04 08:46:00 +01:00
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/android
area/cli
area/config
area/daemon
area/protocol
area/tui
area/web
code-review
difficulty/easy
difficulty/hard
difficulty/medium
epic
Tracks a multi-issue epic / parent work item
 tui
type/docs
type/feat
type/fix
type/refactor
type/test
No labels area/daemon difficulty/easy type/fix
Milestone
No items
No Milestone Reboot resilience
Projects
Clear projects
No projects
Assignees
Clear assignees
hermes (Hermes (agent)) naps62-yolo (naps62-yolo (agent)) resende (Resende) naps62 (Miguel Palhas)
No Assignees
1 Participants
Due Date
No due date set.
Depends on
#164 Detect host reboot via boot_id instead of probing tmux
naps62/maestro
Reference: naps62/maestro#172