ISS-008: A killed polecat's rebase state survives in a reused worktree and VOIDs every future merge gate there #1

New issue

Open

opened 2026-09-02 02:23:43 +00:00 by forgejo-admin · 0 comments

forgejo-admin commented

2026-09-02 02:23:43 +00:00

Owner

Migrated from gc-scratch/issues/ISS-008-stale-rebase-state-voids-worktree-gate.yml on 2026-09-01. That directory is a local YAML tracker in the gc-scratch city; this repo is now the home for these defects.

id: ISS-008
title: A killed polecat's rebase state survives in a reused worktree and VOIDs every future merge gate there
type: bug
status: open
priority: P2
component: city workspace reuse (polecat worktree gitdirs) / merge-gate.ts mid-rebase detection
created: 2026-08-31
reported_by: psbanka
upstream: ce-x51
description: |
  Polecat worktrees are reused across beads. The worktree's gitdir lives at
  `/Users/pbanka/hobby/celilo/.git/worktrees/<polecat>/`. When a polecat
  session dies mid-rebase, git's `rebase-merge/` state directory survives in
  that gitdir. Git itself considers no rebase in progress (`git status` is
  clean and the next occupant can branch and commit normally), so nothing
  surfaces the debris. But merge-gate.ts fails closed on exactly this signal:
  `existsSync(gitDir/rebase-merge)` returns "mid-rebase; no verdict is
  possible here" and exits 2 (VOID) for every future bead worked in that
  worktree, until a human-looking agent notices and deletes the directory by
  hand.

  Measured on the gastown.furiosa worktree on 2026-08-31 while landing ce-x51:
  the gate went VOID with "mid-rebase"; the `rebase-merge/` dir was dated
  2026-08-29 12:43 and belonged to a dead session working polecat/ce-91c (a
  "salvage uncommitted rictus work" rebase that the refinery had since
  completed in a different worktree, gastown.nux, against
  polecat/ce-91c-rebased). The debris held no unpushed work (its orig-head
  equaled the pushed origin/polecat/ce-91c tip), so removal was safe. Nothing
  in the workspace-setup formula step checks for or clears stale rebase
  state, so the next occupant inherits a worktree that can never produce a
  gate verdict.
evidence:
  - Gate run 2026-08-31, /tmp/gate.log: "merge-gate: VOID — <worktree> is
    mid-rebase; no verdict is possible here" (merge-gate.ts:654-656).
  - Debris: gitdir rebase-merge/ dated 2026-08-29 12:43, head-name
    refs/heads/polecat/ce-91c, todo entries referencing dead rictus-session
    salvage commits.
  - git status in the same worktree: clean, on the new occupant's branch
    (polecat/ce-x51), one commit ahead — git itself saw no rebase.
  - The real ce-91c rebase completed in the refinery worktree
    (bead metadata: rebased_branch polecat/ce-91c-rebased, work_dir
    gastown.nux), confirming this state was abandoned, not in-flight.
proposed_fix: |
  Two cheap halves. (1) workspace-setup (or the witness recovery path) detects
  a `rebase-merge`/`rebase-apply` dir in the worktree gitdir when no rebase is
  actually in progress for the current session and reports it, so the next
  occupant does not inherit silent VOID. (2) Optionally, merge-gate.ts's
  mid-rebase failure could name the age of the state directory (mtime of
  rebase-merge/) so a stale-debris VOID is distinguishable from a live rebase
  in the verdict text itself.

Migrated from `gc-scratch/issues/ISS-008-stale-rebase-state-voids-worktree-gate.yml` on 2026-09-01. That directory is a local YAML tracker in the gc-scratch city; this repo is now the home for these defects. ```yaml id: ISS-008 title: A killed polecat's rebase state survives in a reused worktree and VOIDs every future merge gate there type: bug status: open priority: P2 component: city workspace reuse (polecat worktree gitdirs) / merge-gate.ts mid-rebase detection created: 2026-08-31 reported_by: psbanka upstream: ce-x51 description: | Polecat worktrees are reused across beads. The worktree's gitdir lives at `/Users/pbanka/hobby/celilo/.git/worktrees/<polecat>/`. When a polecat session dies mid-rebase, git's `rebase-merge/` state directory survives in that gitdir. Git itself considers no rebase in progress (`git status` is clean and the next occupant can branch and commit normally), so nothing surfaces the debris. But merge-gate.ts fails closed on exactly this signal: `existsSync(gitDir/rebase-merge)` returns "mid-rebase; no verdict is possible here" and exits 2 (VOID) for every future bead worked in that worktree, until a human-looking agent notices and deletes the directory by hand. Measured on the gastown.furiosa worktree on 2026-08-31 while landing ce-x51: the gate went VOID with "mid-rebase"; the `rebase-merge/` dir was dated 2026-08-29 12:43 and belonged to a dead session working polecat/ce-91c (a "salvage uncommitted rictus work" rebase that the refinery had since completed in a different worktree, gastown.nux, against polecat/ce-91c-rebased). The debris held no unpushed work (its orig-head equaled the pushed origin/polecat/ce-91c tip), so removal was safe. Nothing in the workspace-setup formula step checks for or clears stale rebase state, so the next occupant inherits a worktree that can never produce a gate verdict. evidence: - Gate run 2026-08-31, /tmp/gate.log: "merge-gate: VOID — <worktree> is mid-rebase; no verdict is possible here" (merge-gate.ts:654-656). - Debris: gitdir rebase-merge/ dated 2026-08-29 12:43, head-name refs/heads/polecat/ce-91c, todo entries referencing dead rictus-session salvage commits. - git status in the same worktree: clean, on the new occupant's branch (polecat/ce-x51), one commit ahead — git itself saw no rebase. - The real ce-91c rebase completed in the refinery worktree (bead metadata: rebased_branch polecat/ce-91c-rebased, work_dir gastown.nux), confirming this state was abandoned, not in-flight. proposed_fix: | Two cheap halves. (1) workspace-setup (or the witness recovery path) detects a `rebase-merge`/`rebase-apply` dir in the worktree gitdir when no rebase is actually in progress for the current session and reports it, so the next occupant does not inherit silent VOID. (2) Optionally, merge-gate.ts's mid-rebase failure could name the age of the state directory (mtime of rebase-merge/) so a stale-debris VOID is distinguishable from a live rebase in the verdict text itself. ```

forgejo-admin referenced this issue

2026-09-02 13:47:29 +00:00

Pool triggers demand nine worktree-provenance keys that only gc worktree ensure writes, so a pack using worktree-setup.sh stalls its pool permanently #7

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

celilo/gascity#1

No description provided.

Rows
Columns