fix(worktree): bound git ops and always clear the setup spinner

[frankh]

Problem

Some tasks get stuck forever on the "Setting up worktree…" spinner with no error. Two independent causes:

1. Unbounded git ops under the write lock (the real hang). Every new local task runs WorktreeManager.createWorktree({ fetchBeforeCreate: true }), which does git fetch origin <branch> inside GitOperationManager.executeWrite. If that fetch blocks (network stall, a credential helper waiting on stdin, an auth prompt) the operation promise never settles, so the finally { releaseWrite() } never runs — the per-repo write lock is held forever and every subsequent worktree creation for that repo queues behind it. One bad fetch strands many tasks. The raw git worktree add and post-checkout hook spawns likewise had no timeout.

2. Leaked spinner on failure. TaskCreationSaga calls setProvisioningActive before the worktree step but only calls clearProvisioning on the happy path. The Saga base class catches any thrown step, rolls back, and returns {success:false} without ever reaching the clear — so even once a hang becomes an error, the spinner stays up.

Changes

• packages/git/src/worktree.ts
  • spawnWorktreeAdd: kill + reject on a 60s timeout.
  • runPostCheckoutHook: kill + resolve a non-fatal warning on a 120s timeout.
  • New fetchRefWithTimeout helper: wraps the fetch in an AbortController (60s) and threads the signal through executeWrite, which aborts the git subprocess and releases the write lock. Used by resolveFreshBaseRef (default new-task path) and createWorktreeForRemoteBranch.
• packages/core/src/task-detail/taskCreationSaga.ts: wrap the saga body in try/finally so clearProvisioning always runs, tearing down the spinner and letting the existing error toast in useTaskCreation surface. Removes the now-redundant mid-flow clear.

Testing

• pnpm --filter @posthog/core test taskCreationSaga — 16 pass, incl. two new cases asserting clearProvisioning fires on both the worktree failure and happy paths.
• pnpm --filter @posthog/git test worktree — 59 pass; fetch paths now route through fetchRefWithTimeout (incl. the existing unreachable-remote fallback and remote-branch fetch cases).
• @posthog/git typechecks clean.

---

Created with PostHog Code

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 6ba7c6e.}

[greptile-apps]

Comments Outside Diff (2)

1. packages/core/src/task-detail/taskCreationSaga.test.ts, line 9-59 (link)

   New tests not parameterized

   The two new cases test the same invariant — clearProvisioning is always called — under success and failure conditions. Per the team's preference for parameterised tests, these could be expressed as a single it.each block with [true, false] (or a descriptive table) controlling the mock setup, making the shared guarantee and its two scenarios explicit in one place.

   Context Used: Do not attempt to comment on incorrect alphabetica... (source)

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

2. packages/git/src/worktree.ts, line 469-480 (link)

   Double-reject possible after SIGKILL timeout. When the timer fires it calls proc.kill("SIGKILL") and then reject(...). The resulting close event always fires asynchronously with code = null; because null !== 0 is true, the handler calls reject(...) a second time. JavaScript ignores the second call silently, but it will produce a misleading "exited with code null" error message in the reject argument that could surface in logs or test output. Adding an early-return guard makes the intent clear.

_{Reviews (1): Last reviewed commit: "fix(worktree): bound git ops and always ..." | Re-trigger Greptile}