fix(server): start-from-origin worktrees no longer wait on a full git fetch

[gsimone]

Summary

• Creating a worktree with Start from origin ran git fetch origin (every remote branch) under the default 30s timeout. A slow full fetch aborted the new thread even when origin/<branch> was already on disk.
• Bootstrap now uses the local remote-tracking commit when it exists, and only then fetches that one branch (fetchRemoteTrackingBranch). A failed narrow fetch still fails the dispatch and rolls the provisional thread back — it does not silently fall back to local main.
• Related: fix(web): retry failed thread bootstraps with a fresh id #7664 already rotates the draft ID after cleanup; this does not change that order. Distinct from fix(server): fall back to local worktree base when origin fails #7667, which degrades to the local branch after any origin error.

Test plan

• New thread, Start from origin, local origin/main present: worktree is created without waiting on a full git fetch origin
• Same, with origin/main missing locally: only that branch is fetched, then the worktree is created
• Narrow fetch failure: dispatch errors, thread is removed, retry is not stuck on "already exists" (Nightly with fix(web): retry failed thread bootstraps with a fresh id #7664)
• Repo with no origin remote still uses the local base branch

Focused: vp test run apps/server/src/server.test.ts -t "bases a start-from-origin|fetches only the requested origin|fails start-from-origin|falls back to the local base|bootstraps first-send worktree"

Generated with Cursor Grok 4.6.

Made with Cursor

Note

Fetch only requested branch for start-from-origin worktrees in ws.ts

• The thread.turn.start bootstrap handler in ws.ts now resolves the local origin tracking commit first, skipping any fetch when it is already available.
• When the local ref is missing, the handler fetches only the selected remote branch via the new GitWorkflowService.fetchRemoteTrackingBranch operation instead of doing a whole-remote fetch.
• A nonzero Git command failure from the narrow fetch falls back to the local base branch; other failures abort worktree preparation and trigger thread cleanup.
• Risk: the removed whole-remote fetch means recently pushed commits on other branches will not be present during bootstrap. Reviewers should check the fallback logic in the thread.turn.start handler in ws.ts and the new fetchRemoteTrackingBranch delegation in GitWorkflowService.ts.

^{Macroscope summarized eb64f29.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 1372661c-54bf-4406-beed-a0237b3a3dcb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved at eb64f29

Macroscope's review found this PR approvable — This is a focused server-side fix that avoids blocking on a full origin fetch by reusing cached tracking refs and fetching only the requested branch when necessary. Its runtime impact is confined to start-from-origin worktree bootstrap, with targeted tests covering fallback and failure paths.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

fetchRemoteTrackingBranch is typed Effect<void, GitCommandError>, so the instanceof GitCommandError guard can never be false and this hand-rolls recovery (match + re-fail) for a statically known tagged failure. The convention for a structural predicate on an underlying platform code is Effect.catchIf, which is also the existing idiom for GitCommandError recovery in this codebase (GitManager.ts uses Effect.catchIf(isNotGitRepositoryError, ...)). Consider:

.pipe(
  Effect.as(true),
  Effect.catchIf(
    (error) => error.exitCode !== undefined && error.exitCode !== 0,
    () => Effect.succeed(false),
  ),
);

That also lets the now-unused GitCommandError value import added at line 31 be dropped (the type is already implied by the error channel).

^{Posted via Macroscope — Effect Service Conventions}

[gsimone]

Unhappy with this, closing but maybe someone will find this as evidence for a similar change later