[bug][reconciler] Post-merge cleanup skips safe worktree removal when remote delete is blocked by worktree_binding #851

New Issue

2026-07-23T15:31:38-05:00

jcwalker3 commented

2026-07-23 15:31:38 -05:00

Problem

gitea_reconcile_merged_cleanups execute path uses continue when remote branch deletion is blocked by active ownership (including worktree_binding). That skips the subsequent remove_local_worktree step even when the local worktree is independently clean and safe to remove.

Reproduction evidence (PR #848 / issue #844)

PR #848 is merged; issue #844 is closed.
No active reviewer or merger lease remains.
Worktree: branches/fix-issue-844-exclude-epic-containers
Worktree is clean and safe to remove.
Report: local_worktree.safe_to_remove_worktree=true, remote_branch.safe_to_delete_remote=true.
During execution, remote deletion is correctly blocked by ownership category worktree_binding.
The execute loop then continues, so remove_local_worktree is never attempted.
The worktree remains, and that same binding continues to block subsequent remote branch deletion.

Required behavior

Preserve fail-closed ownership protection for remote branch deletion.
Do not skip a worktree that is independently safe to remove merely because remote deletion is blocked by that same worktree_binding.
Execution order for this case:
- remove the clean, owned worktree;
- reassess branch ownership afterward;
- delete the remote branch only if it is then independently safe.
A blocked remote deletion for a different ownership category must not authorize unsafe cleanup (remote delete still fail-closed; dirty/foreign worktrees remain protected).
Unrelated PRs/worktrees are untouched.
Dry-run accurately describes the execution order.
Partial failures remain resumable and idempotent.

Non-goals

Manual cleanup of PR #848 as part of implementing this fix (unless the new implementation has passed tests and the canonical reconciler operation can be pinned exclusively to #848).
Changes to PR #845, #846, or #849 scope.
Weakening ownership guards for remote deletion.

Acceptance criteria

Remote branch safe, but blocked only by target worktree_binding → worktree removal still occurs.
After worktree removal, ownership is reassessed and remote is deleted only if independently safe.
Dirty or foreign worktrees remain protected.
Unrelated PRs/worktrees are untouched.
Dry-run describes remove-then-reassess-then-delete order when applicable.
Partial failures remain resumable and idempotent.
Regression tests cover the cases above.

References

Demonstrated by PR #848 / issue #844 post-merge cleanup
Code path: gitea_reconcile_merged_cleanups execute loop (continue after ownership block)

## Problem `gitea_reconcile_merged_cleanups` execute path uses `continue` when remote branch deletion is blocked by active ownership (including `worktree_binding`). That skips the subsequent `remove_local_worktree` step even when the local worktree is independently clean and safe to remove. ## Reproduction evidence (PR #848 / issue #844) - PR #848 is merged; issue #844 is closed. - No active reviewer or merger lease remains. - Worktree: `branches/fix-issue-844-exclude-epic-containers` - Worktree is clean and safe to remove. - Report: `local_worktree.safe_to_remove_worktree=true`, `remote_branch.safe_to_delete_remote=true`. - During execution, remote deletion is correctly blocked by ownership category `worktree_binding`. - The execute loop then `continue`s, so `remove_local_worktree` is never attempted. - The worktree remains, and that same binding continues to block subsequent remote branch deletion. ## Required behavior 1. Preserve fail-closed ownership protection for remote branch deletion. 2. Do not skip a worktree that is independently safe to remove merely because remote deletion is blocked by that same `worktree_binding`. 3. Execution order for this case: - remove the clean, owned worktree; - reassess branch ownership afterward; - delete the remote branch only if it is then independently safe. 4. A blocked remote deletion for a *different* ownership category must not authorize unsafe cleanup (remote delete still fail-closed; dirty/foreign worktrees remain protected). 5. Unrelated PRs/worktrees are untouched. 6. Dry-run accurately describes the execution order. 7. Partial failures remain resumable and idempotent. ## Non-goals - Manual cleanup of PR #848 as part of implementing this fix (unless the new implementation has passed tests and the canonical reconciler operation can be pinned exclusively to #848). - Changes to PR #845, #846, or #849 scope. - Weakening ownership guards for remote deletion. ## Acceptance criteria - [ ] Remote branch safe, but blocked only by target `worktree_binding` → worktree removal still occurs. - [ ] After worktree removal, ownership is reassessed and remote is deleted only if independently safe. - [ ] Dirty or foreign worktrees remain protected. - [ ] Unrelated PRs/worktrees are untouched. - [ ] Dry-run describes remove-then-reassess-then-delete order when applicable. - [ ] Partial failures remain resumable and idempotent. - [ ] Regression tests cover the cases above. ## References - Demonstrated by PR #848 / issue #844 post-merge cleanup - Code path: `gitea_reconcile_merged_cleanups` execute loop (`continue` after ownership block)

jcwalker3 added the status:ready type:bug labels 2026-07-23 15:31:38 -05:00

jcwalker3 referenced this issue from a commit

2026-07-23 15:41:51 -05:00

fix: remove safe worktrees before reassessing remote delete ownership (#851)

jcwalker3 referenced a pull request that will close this issue

2026-07-23 15:42:53 -05:00

fix: remove safe worktrees before reassessing remote delete ownership (#851) #852

jcwalker3 added status:pr-open and removed status:ready labels 2026-07-23 15:42:54 -05:00

sysadmin referenced this issue

2026-07-23 16:21:22 -05:00

fix: remove safe worktrees before reassessing remote delete ownership (#851) #852

sysadmin referenced this issue