Skip to content

Auto-isolation is decided from a registry read taken before the session announces itself, so concurrent sessions both stay on the primary checkout #1200

Description

@justrach

Symptom

A session only mints its own worktree when another live session already claims the checkout. Two sessions started at nearly the same time both observe the checkout as unclaimed and both run directly on the shared primary working tree, so their edits can collide. Whether an otherwise identical launch lands on an isolated worktree or the primary checkout depends purely on registry timing — the same command can report either worktree: .graff/worktrees/... or no worktree at all.

Root cause

  • src/session_start.zig:145 calls task_workspace.maybeAutoIsolate(...) during boot.
  • shouldAutoIsolate (src/task_workspace.zig:64-67) gates entirely on claimed, which comes from checkoutClaimed (src/task_workspace.zig:307) — documented read-only: // Read-only: does not announce.
  • This session's own presence record is written much later, in presence.announce (src/session_run.zig:365).

The decision is therefore check-then-mint across processes with no lock and no self-claim: every session started inside that window sees "unclaimed" and skips isolation.

Fix

Take the claim before deciding: announce (atomically register-and-check under the registry) first, then mint the worktree if the checkout is contended — so the check and the mint cannot interleave across processes.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions