Conversation
…g-blocked poller Two coupled defects left a review slot orphaned with a stale status.yaml after a review-routed task was accepted and merged (observed live 2026-08-17, PR #577). 1. Dialog-block wedged the status poller. When a Claude pane parks on a blocking modal (`dialog:question`, trust, permission), neither the busy footer nor the ready input box is drawn and Claude commonly clobbers the `shelbi:` pane-title marker with the modal's chrome. `poll_one` then found no live state AND no title marker and `return`ed early *before* `save_workspace_status`, so status.yaml froze at the pre-dialog state (`working`) and `last_seen` stopped advancing for the life of the modal — hours, in the incident. Fix: `maybe_emit_dialog_event` now returns the detected dialog kind, and `poll_one` folds it into the persisted state — a detected modal records `Blocked` (keeping `last_seen` fresh and honest), which clears on the next live busy/ready sample once the human answers. 2. Orphaned review pane was never reaped without a serving marker. `maybe_reap_orphaned_review_slot` gated the reap on the `.claude/shelbi-review-loaded` marker. A slot that was dispatched a review task but blocked on a dialog before its branch server came up never got that marker written, so when the task was accepted (review → done) nothing tore the pane down — and the dev-orphan reaper deliberately skips `review` slots, so the pane lingered as an `orphaned session`, keeping the heartbeat `idle_workspaces` count dishonest. Fix: drop the marker gate; the liveness/user-shell probe is the real guard, so a live non-user-shell agent pane with no assigned review task is reaped regardless of marker. A user shell / dead / unreachable slot is still left alone. Also: on any reap (review + dev orphan) and on the TUI accept teardown (`close_review_window`), clear the freed slot's status.yaml via the new `shelbi_state::clear_workspace_status`. A killed pane emits no further markers, so the poller can never refresh the file; left in place it would report the agent's last state frozen forever. Cleared, the slot reads as idle in both the board-derived `workspace list` and `workspace status`. Decisions made without asking: - Persist `Blocked` (not a new Idle variant) for a detected modal — it's the honest state and rides the existing decide()/dedupe machinery. - Clear (delete) status.yaml on reap rather than write a synthetic idle state: there is no agent to describe, and the whole system already derives idle-ness from the board + live probe, not a persisted "idle" marker. - Reap is left to the poller (covers CLI `task move`, hand board moves, and eviction uniformly); the CLI accept path is not given its own teardown call. cargo build/test/clippy --workspace all pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
jlong
deleted the
jlong/review-slot-left-orphaned-with-stale-status-yaml-after-accept-merge-dialog-block-wedges-poller
branch
August 18, 2026 14:58
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Task
After a review-routed task is accepted (moved to done) and merged, the review workspace can be left as an
orphaned sessionwith a stalestatus.yamlinstead of being cleanly torn down and returned toidle. Observed live on 2026-08-17.Current Behavior
Timeline for workspace
reviewon taskprovisioning-never-destroy-user-claude-skills-files-mount-shelbi-s-without-committing:status=review-load detail=auto-loading_branch_onto_idle_review_slot), boots server,serving.working -> blocked reason=dialog:question. This is the last status line the review workspace ever emits.~/.shelbi/workspaces/review/status.yamlfreezes atstate: working,last_seen: 2026-08-17T19:03:03Z.merge ... status=ok detail=pr:577:...) and moves review → done. The review server pane is NOT cleanly torn down.shelbi workspace listshowsreview hub - conventional orphaned session, andshelbi workspace status reviewstill reportsstate: working, last_seen 5h agowith(idle)task.So two coupled defects:
dialog:questionblock and never recovers —status.yamlgoes stale (frozen atworking).orphaned sessionrather than a cleanidleslot.Meanwhile the hub heartbeat still counts
idle_workspaces=6(including this slot), so it would route the next review-routed task onto a slot that is actually in an orphaned/stale state — risking a failed or confused review-load.Expected Behavior
idlewith a freshstatus.yaml(notorphaned session, not frozenworking).dialog:question(or any) block on a review workspace must not permanently wedge its status poller — status reporting should resume (or the pane should be recovered by the supervisor) rather than going silent for hours.status.yamlshould not remain frozen at a staleworking/last_seenonce the task is gone; it should reflect the real current state (idle) or be cleared.idle_workspacescount should not include a slot that is actually orphaned/wedged, or the orphan should be reaped so the count is honest.Acceptance Criteria
shelbi workspace listshows the review slot asidle, notorphaned session.shelbi workspace status <review>shows a fresh, currentstatus.yamlreflecting idle (not a staleworkingfrozen at the dialog-block timestamp).dialog:questionblock on a review workspace does not permanently stop its status poller; status updates resume (or the supervisor recovers the pane).workspace stop/recovery.idle_workspacesin the heartbeat reflects genuinely available slots (an orphaned/wedged review slot is either reaped or not counted).cargo build --workspace,cargo test --workspace, andcargo clippy --workspace --all-targets -- -D warningspass.Context
Discovered while orchestrating on 2026-08-17: after merging PR #577 (the
.claudeprovisioning fix) via review → done, thereviewslot was left orphaned with a status.yaml frozen at the earlierdialog:questionblock (19:03), 5h stale. Not currently blocking (no queued review tasks) but leaves the slot in a dirty state and makes the heartbeat idle count dishonest. Likely lives in the review-load / review-window teardown and the workspace status poller (seeshelbi-orchestratorreview/poller code and the review-window auto-recover path). The unrelatedproject=contextstore ... supervision=gave-up reason=review-load-crash-loopline at 18:32 is a different project and out of scope for this task, though it may hint the review-load path is fragile under blocks.Auto-opened by Shelbi — review at: /Users/jlong/.shelbi/projects/shelbi/tasks/review-slot-left-orphaned-with-stale-status-yaml-after-accept-merge-dialog-block-wedges-poller.md