git: add bounded pages for large tracked-file patches
A changed file's patch currently stops at the per-file/reply budget. Add an opt-in bounded byte-page response to git.diff and git.checkpoint.diff, and a sorted file cursor, so a reader can fetch a complete large tracked-file patch without one oversized JSON reply. Existing callers retain their current response shape.
Leo asked: “But, like, the diff viewer and the editor, I feel like, okay, either you can raise the limits more than that, or you can say just do, like, some bigger kind of optimizations if we even care. Because, like, aren't these inherently, like, pretty hefty things anyways? So.”
Each raw patch page retains at most 512 KiB in memory. The shared confined Git runner captures and hashes the output once into a private, immediately unlinked disk file. Continuations require the first page's revision (SHA-256 over the patch digest and the page-zero listing, so a continuation always replays the listing its page zero returned) and read only the requested range of that immutable capture; base64 preserves UTF-8 sequences split across page boundaries. A missing/expired capture requires a fresh read from offset zero. Offsets and lengths use the resource API's exact decimal-string wire format. Git timeouts and process cleanup use the existing runner.
This is the transport prerequisite. It changes no native or web rendering and does not yet remove the viewer's tooLarge result. The native adapter must consume the pages in a dependent change. Legacy reply and untracked-file limits remain unchanged; no cap was raised without a measured reason. The active-capture cache is scoped to the repository, comparison, path and context. It keeps at most eight captures with a 256 MiB retention target (one larger active capture is allowed). Idle entries expire after two minutes when the next page request prunes the cache; replacement, eviction and process exit close the anonymous files. No timer or service is added. Later pages do not regenerate or re-hash the diff.
Validation: exact-head fleet run 40792127918 (receipt 2458e6026f7e42b382a0a5c37429f9ad.json) passed at 659ca591ab850f77b315ee35b38002b66e5bd1c6: the focused git_diff_context suite and clippy path completed successfully. It also proves immutable capture bytes after working-file changes, root and nested directory path filters, cache scope/eviction/idle expiry, and generated descriptor freshness. The native sidecar is a separate dependent PR.
Repair at 2f2eb529 (drain lander): merged feat-cmux-next (git runner now takes both address_space_limit and window_offset; descriptors re-synced) and fixed the BLOCK at 659ca591 (an identical patch with a changed listing replayed the first listing's complete). Regression test same_patch_with_a_different_listing_keeps_each_listing_with_its_revision. Fleet: clippy -D warnings on cmux-tui-core/cmux-git, git_ops::diff and git_diff_context pass at 2f2eb529 (fast-checks run 40977607834).
The numbers below are from the earlier, pre-cache implementation, retained as a baseline. The current implementation retains the same measured first-page and complete-read behavior; the focused exact-head run above verifies the repair.
Performance
| Metric | Before | After | Delta | Harness or run |
|---|---|---|---|---|
| Recoverable patch bytes | 262,139 (truncated) | 10,500,187 (complete) | +10,238,048 bytes | Fleet job 4703971b4f331fda41b751dc, same 300,000-line fixture |
| First reply latency | 126.98 ms (262,139 bytes) | 102.80 ms (524,288 bytes) | -24.18 ms | Same harness and process; run 40784031532 |
| Complete patch load | Unavailable (truncated) | 174.35 ms, 21 pages | New complete read | Same harness and process; run 40784031532 |
| Retained raw patch bytes per page | 262,139 bytes | 524,288 bytes max | +262,149 bytes bounded page | drain_window unit test and integration page assertions |
Agent session: agent session