🤖 perf: re-read git status after a passive fetch settles

[ThomasK33]

Problem

A passive git fetch started by an ordinary refresh (subscription, window focus, or a file-modifying tool) never triggers a status re-read after it settles. GitStatusStore.updateGitStatus() starts the fetch in the background (tryFetchWorkspaces → fetchWorkspace) and reads status at the same time. When the fetch, or one of its delayed secondary-repo fetches, brings new remote refs, the footer's ahead/behind and incoming counts keep showing the pre-fetch refs until the next trigger.

This behavior already exists on main. Before #5566, unrelated workspace metadata events re-read status on every event, which hid the problem in busy sessions. #5566 removes that churn on purpose. It adds a post-fetch re-read only for fetches forced by a checkout change.

Reproduction

1. Open workspace A whose branch tracks a remote.
2. Push a new commit to A's upstream from another clone.
3. Focus the Xum window. Xum reads status and starts a passive fetch at the same time.
4. Wait for the fetch to finish. The footer still shows the old behind count until the next focus, workspace switch, or file edit.

Desired behavior

After a passive fetch (and its secondary-repo fetches) succeeds, read status once more, with a bound. Constraints:

1. lastFetch is recorded before the secondary fetches settle, and a completion-triggered refresh can wait through the 3 s debounce. Either delay can make the fetch key due again. A naive "refresh after every fetch" can then loop: fetch → refresh → fetch.
2. Do not double the status runs for every focus or file trigger when no refs changed. Consider comparing ref state, or re-reading only when the fetch output reports updated refs.

Tests: one status re-read after a fetch that updated refs, no loop across the debounce and backoff windows, and no extra runs when nothing changed.

Owner and trigger

Owner: @ThomasK33 (perf owner). Follow-up trigger: after #5566 lands.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

[ThomasK33]

An additional case from the #5566 review (round 6): when a forced fetch after a checkout change fails transiently, its mark is already consumed. This prevents a retry loop. The next fetch then waits for the next focus, file, or subscription trigger. A bounded post-fetch policy here can also cover a bounded retry for failed forced fetches.

[ThomasK33]

One more low-severity case from the #5566 review (round 6, thread on statusRefreshInputs.ts): when a workspace leaves the active metadata map (for example, on archive) and returns while unsubscribed, getStatusInputChanges records no change. The PR/stack caches and the fetch backoff survive that gap. If its checkout inputs changed while it was absent and it is reopened inside the cache windows, the old data stays until the next trigger. Fix: treat a reappearing ID that still has cached state as changed. The trigger is very unlikely: unarchive changes no checkout input, and the UI has no checkout rename.

[ThomasK33]

From #5566 review round 7 (PRStatusStore, counterpart of the failed-forced-fetch case): refreshAll deletes the checkout-change mark before the PR and stack probes run. If the one metadata-driven probe hits a transient executeBash failure, the PR entry keeps the previous checkout's PR as an error, and the stack may become null. With no churn, this persists until a focus or resubscription. Desired: keep the mark until both probes succeed, or until a bounded number of attempts, with the same policy as the git fetch.

[ThomasK33]

From #5566 review round 8: DETECT_PR_SCRIPT (and the stack command gh stack view --json 2>/dev/null || echo '{"no_stack":true}') turn any gh failure (network, auth, rate limit) into a successful "no PR" / "no stack" answer. That behavior predates #5566. With #5566's bounded retry for checkout-change probes, such a masked failure counts as success, so the retry never runs, and a checkout change made during a gh outage shows "no PR" until the next focus or subscription. Desired: give the detection scripts a distinct error output (for example {"gh_error":"..."} when gh exits non-zero for a reason other than "no PR found"). The store would then treat that output as a failed probe, so it is retried and never cached as a negative answer.

[ThomasK33]

Changed behavior after #5566 (tracked here, owner: the perf program conductor; trigger: next perf optimization batch after the bench harness lands, or any user report of a missing PR link):

• The PR-detection script and the stack command turn every gh error into "no PR" / "no stack". This already happens on main.
• Before 🤖 perf: skip git/PR status refresh on unrelated workspace metadata events #5566, unrelated metadata events re-probed PR status and so repaired that state by accident. 🤖 perf: skip git/PR status refresh on unrelated workspace metadata events #5566 removes that churn (619 → 0 git-status calls per minute under churn) and with it the accidental retry.
• Result: if you rename or switch the checkout of a workspace during a gh outage, its PR link disappears until the next focus or file trigger. The new bounded retry (3 attempts, 5 s apart) does not help, because the scripts never report the error.
• Fix: make the detection scripts report gh failures separately from "no PR", so that PRStatusStore keeps the previous value and retries.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high