fix(server): clean up failed checkpoint writes

[im-kvijay]

Why

Checkpoint capture writes new objects into the shared repository store. Failure, timeout, or interruption during staging can leave temporary packs that accumulate across attempts, as reported in #3646.

Proposal: #9808

Closes discussions

• Clean up failed checkpoint writes #9808

What Changed

Capture now owns a scoped directory for its index and new objects, reads existing objects through Git alternates, and publishes completed objects before updating the checkpoint ref. Failed staging cleans only its own storage. Snapshot contents and the user's index are preserved.

Git's temporary-object directory prefix allows normal pruning to reclaim stale crash leftovers.

Validation

• 68 focused tests pass, plus server and contracts typechecks, targeted lint, and formatting.
• Three fault-injection regressions fail against upstream and pass with this patch, verifying cleanup, ref/index preservation, and unrelated packs. Real Git coverage includes large packed-file restoration, linked worktrees, and shared-repository permissions.
• Windows collision behavior is simulated; native Windows was not tested.
• In a local 2,000-file fixture, median capture time changed from 30.6 to 32.0 ms with 10 modified files, and 90.0 to 118.5 ms with all files modified (five runs each). Snapshot trees were identical.

Limits

The 30-second deadline remains: this addresses temporary-pack accumulation, not long captures timing out. Filesystem failure between pack and index publication can leave an unindexed pack requiring cleanup. Private storage adds one alternates level, so repositories near Git's nesting limit can fail capture.

Created with GPT-6 in Codex.

---

Note

Medium Risk
Changes how checkpoint objects are written and published in the live Git object store, but scoped temp dirs, index isolation, and broad regression tests reduce the risk of corrupting user repos or leaving stale packs.

Overview
Checkpoint capture no longer stages new Git objects directly into the shared .git/objects store. GitVcsDriver.captureCheckpoint writes to a scoped temp object database (under the repo objects path, with alternates for existing objects), then publishes loose objects and packs into the real store and updates the checkpoint ref in an uninterruptible block so interruption mid-flight does not leave partial refs or orphan temp packs.

Filesystem failures during publication surface as new VcsCheckpointStorageError (contracts + GitLab CLI error mapping). The old git-common-dir random temp-index approach is removed.

Tests add fault-injection coverage (failure, timeout, interruption, rename collisions, shared-repo permissions) plus integration cases for control characters in paths, large packed files without touching the user index, and linked worktrees.

^{Reviewed by Cursor Bugbot for commit 0a14f55. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Rework GitVcsDriver.captureCheckpoint to clean up failed checkpoint writes

• Checkpoint capture in GitVcsDriver.ts now writes objects to a scoped temporary object database, then publishes loose objects and packs into the shared repository directory before updating the ref
• Publication and ref update run in an uninterruptible region to ensure completion despite interruption
• Adds VcsCheckpointStorageError to vcs.ts and maps it in GitLabCli.ts
• Adds tests for cleanup on failure, timeout, interruption, control characters, large files, and linked worktrees
• Behavioral Change: GitVcsDriver.captureCheckpoint removes the old random temporary-index path generation and git-common-dir helper; filesystem publication failures now throw VcsCheckpointStorageError

^{Macroscope summarized 0a14f55.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR rewrites the production checkpoint-capture path to isolate and manually publish Git objects, with new interruption, concurrency, permission, cleanup, and error-propagation behavior. Despite strong fault-injection and integration coverage, this is a substantial runtime refactor affecting shared repository state and merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}