fix(source-control): huge-status flag permanently disabled all status refresh — commits in the terminal never surfaced - #8570
Conversation
…e huge flag is set Once git status hit the 10,000-entry limit, the huge flag disabled every status-refresh lane — including the push signals (repo metadata watcher, terminal command-finished) that carry the evidence needed to clear it. The flag only clears when a fresh non-huge status result arrives, so the worktree deadlocked into stale Source Control and explorer badges until an app restart. Split the gate: evidence-free interval polling stays paused while huge (preserving the stablyai#7983 idle-CPU fix), but push-signal refreshes now ride the coalesced change-signal lane, so a commit made in the integrated terminal clears the flag and resumes normal polling. A visibilitychange listener (active only while huge pauses polling) catches up signals dropped behind a hidden window, matching the becoming-visible catch-up the normal lane already has.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughGit status polling now separates base fetch conditions from the huge-status interval guard. Interval polling pauses while the huge flag is active, while repository change signals can still trigger status refreshes. A visibility-change listener retries status fetching when a hidden window becomes visible. Tests add document stubbing and cover both push-signal refreshes during huge-status pauses and visibility-triggered catch-up. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Taking a look! |
Summary
Once
git statushits the 10,000-entry limit (DEFAULT_GIT_STATUS_LIMIT), the huge flag (gitStatusHugeByWorktree) disabled every status-refresh lane for that worktree — interval polling, the 30s terminal-only backstop, file-watch refreshes, and the push signals (repo-metadata watcher, terminal command-finished). But the flag only clears when a fresh status result arrives withdidHitLimit=false, so the worktree deadlocked into permanently stale Source Control and file-explorer badges: commits made in the integrated terminal were never reflected until an app restart. The remaining escape hatches (the one-shot .gitignore toast, a git mutation through Orca's UI) don't fire for terminal-driven workflows, and the toast doesn't appear at all when the over-limit state was transient (findHugeFoldersToIgnorefinds nothing).Repro (before this fix): create >10,000 untracked files in a worktree → banner appears → remove/commit them from the integrated terminal →
git statusis clean but the panel and explorer badges keep the stale entries indefinitely; only an app restart recovers.The fix splits the gate in
useGitStatusPolling:shouldPollActiveWorktreeGitStatus(includes the huge check) still gates evidence-free interval polling — the [Bug]: Continuous full-untracked Git polling consumes CPU in large monorepos on v1.4.130 #7983 idle-CPU protection is preserved: while huge, no timers run.canFetchActiveWorktreeGitStatus(everything except the huge check) now gatesrunFetchStatusand the push-signal subscription, so signals that carry evidence of a change (a commit's.gitmetadata write, a finished shell command) ride the coalesced change-signal lane, run one status, and let a non-huge result clear the flag and resume normal polling.visibilitychangecatch-up listener (active only while huge pauses polling) covers signals dropped behind a hidden window — e.g. an agent committing while Orca is minimized — matching the becoming-visible catch-up semantics the normal lane already has viainstallWindowVisibilityInterval.File-watch refreshes stay gated on the huge flag (unchanged): file churn is high-frequency on exactly the repos that trip the limit. Push signals are low-frequency and paced by the coalescer's 3s floor plus the slow-task backoff.
Screenshots
No visual change (the existing "too many changes" banner now clears itself once a signal-triggered status runs).
Testing
pnpm lintpnpm typecheckpnpm test— all renderer suites pass (right-sidebar: 150 files / 1,259 tests). 17 pre-existing failures insrc/main/src/relayreal-git-binary integration tests reproduce identically on a pristinemaincheckout on this machine (git 2.55.0, macOS) and are unrelated to this renderer-only change.pnpm buildAI Review Report
Ran an adversarial review of the branch (Codex, plus the authoring agent's own pass). Focus areas and results:
runFetchStatusno longer checks the huge flag, so a trailing coalesced run can clear it; push subscriptions stay keyed to repo/worktree identity; no stale closures or listener leaks found; worktree-switch traces (huge→huge, huge→non-huge, hidden transitions) behave correctly.documentavailability — the review flagged that the new visibility effect accesseddocumentunguarded, unlikeinstallWindowVisibilityInterval; fixed by adding the same defensive existence check.visibilitychange/document.visibilityStateare standard DOM APIs identical across platforms.isActiveConnectionReadycondition, so disconnected SSH targets still skip refreshes; push signals for remote repos flow through the same IPC channels as before.Security Audit
No input handling, command execution, path handling, auth, secrets, or dependency changes. The change rearranges existing renderer-side gating of already-established IPC subscriptions (
worktrees:onChanged,worktrees:onGitStatusMetadataChanged, DOMvisibilitychange); no new IPC surface, no new data crosses the preload bridge, and payload handling (repoIdcomparison) is unchanged.Notes
Two residual limitations surfaced by the adversarial review, left out of scope to keep this PR minimal (both are strictly better than the current permanently-stuck behavior; happy to follow up if maintainers have a preferred pacing design):