fix(code): prevent archived tasks from reappearing after archive

[richardsolomou]

Problem

Archiving a task in the sidebar sometimes worked cleanly, sometimes silently re-listed the task a moment later, and sometimes appeared to fail outright. The behaviour was timing-dependent.

Root cause: archiveTaskImperative (apps/code/src/renderer/features/tasks/hooks/useArchiveTask.ts) wrote optimistic updates to the archive queries without first cancelling in-flight refetches. A background refetch (window-focus manager or the 30s task-summaries poll) could land between the optimistic write and the mutation completing, then overwrite the optimistic cache with the still-unarchived server snapshot — making the archived task reappear in the sidebar until the post-mutation invalidateQueries caught up. useDeleteTask already uses the correct cancelQueries-first pattern; archive did not.

Secondary issue: if the archive mutation threw after we'd already called clearTerminalStatesForTask and removeTaskById, the task came back in the sidebar but its terminal state and command-center slot were silently dropped.

Changes

• Call await queryClient.cancelQueries(trpc.archive.pathFilter()) immediately before the optimistic setQueryData calls in archiveTaskImperative. This kills any in-flight archive refetch so it can no longer overwrite the optimistic state. The same fix transitively covers the bulk "Archive prior tasks" loop in SidebarMenu, since every iteration calls archiveTaskImperative and therefore cancels the previous iteration's invalidate-triggered refetch.
• Snapshot the per-task terminal states (keyed by taskId and ${taskId}-*) and the command-center cell index before clearing them. On mutation failure, restore both alongside the existing pin/cache rollbacks via useTerminalStore.setState(...) and useCommandCenterStore.getState().assignTask(cellIndex, taskId).

No new dependencies, no new public API, no behaviour change on the success path beyond eliminating the race.

How did you test this?

• Ran pnpm --filter code typecheck — only the pre-existing workspace-package errors remained (@posthog/git/*, @posthog/platform/*); the edited file is clean.
• Ran npx biome check on the edited file — passes.
• The pre-commit hook (biome check --write + pnpm typecheck on staged files) ran on the commit and passed.
• Did not manually repro in a built Electron app — the race is timing-dependent and easiest to confirm via the symptoms Richard described disappearing after the fix lands.

Publish to changelog?

no

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
apps/code/src/renderer/features/tasks/hooks/useArchiveTask.ts:106-108
**`assignTask` unconditionally steals active-task focus during error recovery**

`assignTask` always sets `activeTaskId` to the newly assigned task (see `commandCenterStore.ts` line 113). In the error path this means: if the archived task was visible in the command center but was *not* the active cell, recovery will incorrectly steal focus to it. For example — user focuses cell 0 (task A), right-clicks task B in cell 2 and archives it, mutation fails → `assignTask(2, taskB)` fires and makes task B the active task, silently stealing focus from task A. The snapshot should also capture the pre-archive `activeTaskId` and restore it explicitly instead of relying on `assignTask`'s side-effect.

_{Reviews (1): Last reviewed commit: "fix(code): prevent archived tasks from r..." | Re-trigger Greptile}