Skip to content

Fix deleted repo group resurrection bug#184

Open
jfversluis wants to merge 1 commit intomainfrom
fix/deleted-group-resurrection
Open

Fix deleted repo group resurrection bug#184
jfversluis wants to merge 1 commit intomainfrom
fix/deleted-group-resurrection

Conversation

@jfversluis
Copy link
Collaborator

Problem

When a user deletes a sidebar group that is linked to a tracked repository, the group reappears ("resurrects") on the next UI state refresh. This happens because ReconcileOrganization() enforces the invariant "every tracked repo must have a sidebar group" — but this conflicts with the user's explicit deletion.

Root Cause

Three code paths in ReconcileOrganization call GetOrCreateRepoGroup, which recreates the group if the repo is still tracked by RepoManager:

  1. Auto-link sessions (line 214): Session's working directory matches a worktree → creates repo group
  2. Reassign orphaned sessions (line 234): Session has WorktreeId but is in _default group → creates repo group
  3. Ensure repo coverage (line 259): Tracked repo has no group → creates repo group

Fix

  • DeletedRepoGroupRepoIds — new HashSet<string> on OrganizationState (persisted to organization.json) that tracks repo IDs whose groups were explicitly deleted by the user
  • GetOrCreateRepoGroup(repoId, name, explicitly) — new explicitly parameter:
    • Implicit calls (from ReconcileOrganization) return null for deleted repos
    • Explicit calls (from repo-add operations) clear the deleted flag and create the group
  • DeleteGroup — now clears WorktreeId on moved sessions for repo groups, preventing ReconcileOrganization from reassigning them via the worktree path
  • Backward compatibility — null-coalesce guard in LoadOrganization handles old organization.json files without the new field

Tests

13 new tests in DeletedRepoGroupResurrectionTests covering:

  • Delete adds to deleted set / non-repo delete doesn't
  • WorktreeId cleared for repo groups / preserved for non-repo groups
  • Implicit GetOrCreateRepoGroup returns null for deleted repos
  • Explicit GetOrCreateRepoGroup clears deleted flag
  • Existing group returned even if in deleted set
  • ReconcileOrganization doesn't resurrect deleted group
  • Session not reassigned after group deletion
  • Serialization round-trip of DeletedRepoGroupRepoIds
  • Legacy JSON backward compatibility
  • Default group deletion is no-op
  • Re-add repo clears deleted flag

All 1157 existing tests pass (1 pre-existing locale-dependent failure unrelated).

When a user deletes a sidebar group linked to a tracked repository,
ReconcileOrganization would immediately recreate it because it enforces
'every tracked repo must have a sidebar group'. This caused the deleted
group to reappear in the sidebar.

Root cause: Three code paths in ReconcileOrganization call
GetOrCreateRepoGroup which recreates the group if the repo is still
tracked by RepoManager.

Fix:
- Add DeletedRepoGroupRepoIds to OrganizationState (persisted to JSON)
  to track repos whose groups were explicitly deleted by the user
- GetOrCreateRepoGroup now accepts an 'explicitly' parameter: implicit
  calls (from ReconcileOrganization) return null for deleted repos;
  explicit calls (from repo-add operations) clear the deleted flag
- DeleteGroup clears WorktreeId on moved sessions to prevent
  ReconcileOrganization from reassigning them via the worktree path
- Null-coalesce guard in LoadOrganization for backward compatibility
  with old organization.json files

Includes 13 new tests covering all scenarios.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant