fix(server): background git status fetches no longer fill the disk with failed repacks - #13812
Conversation
…th failed repacks The status poller's `git fetch` also started `git gc --auto`. When that gc fails (here, a repository with missing objects), Git retries it on every fetch and leaves a full-size tmp_pack_* each time. Pass --no-auto-gc so the background poll never starts repository maintenance. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a focused server bug fix that prevents background status fetches from triggering failed automatic repacks, while leaving user-initiated fetch behavior unchanged. A targeted integration test covers the new behavior, with no schema, security, deployment, or configuration-default changes. You can add or adjust custom eligibility rules. Learn more. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: pingdotgg/t3code/.coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe status fetch command now passes ChangesStatus fetch garbage collection
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to Status polling will avoid triggering automatic repository maintenance, preventing repeated failed repacks from accumulating temporary pack files. No actionable merge risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
One of our machines lost 688 GB to
tmp_pack_*files in.git/objects/pack. T3 Code's background status fetch was the main trigger.Every
git fetchalso startsgit gc --auto. The repo had 120 packs (the auto-gc limit is 50), so gc tried a full repack each time. The repack failed on missing objects, which left a ~245 MB partial pack behind. Git never records that failure when gc runs undergit maintenance run --auto --detach, so the next fetch tried again. The status poller fetches about every 15s, so the leak never stopped.The fix: the status poller now runs
git fetch --no-auto-gc. A background poll should not start maintenance on the user's repo. Fetches, pulls, and commits that users start themselves still run git's normal auto-gc.--no-auto-gcis the older synonym of--no-auto-maintenance, so older Git accepts it too.Tested with a new test: a repo where auto-gc is due. It fails without the flag (2 packs repacked into 1) and passes with it.
Related: #3525 and #4338 cover a different leak, where the 5s fetch timeout kills
index-pack. This PR does not change that.Created with Claude Opus 5.5 in Claude Code.
🤖 Generated with Claude Code
Summary by CodeRabbit