fix: bound aggregate code review diff memory across all files (APP-4827)

[warp-agent-staging]

Summary

Bounds the aggregate memory the local code-review diff-state materializes when loading diffs for a repo. Addresses the dominant facet of the memory spike tracked in APP-4827 (Sentry 7259255054), complementing #13393 (which bounds a single file).

Root cause (from a symbolized heap profile)

The latest macOS event's heap profile sampled ~10.9 GB (internal footprint ~11.6 GB). I symbolized it against the release dSYM. The dominant allocation stacks are all in the code-review diff viewer:

• ~2.6 GB — GlobalBufferModel::populate_buffer_with_read_contents → Buffer::replace_all → BufferSumTree::append_str (loading full file contents into editor buffers)
• ~2.4 GB — CodeEditorModel::rebuild_layout_and_refresh_diff → StyledBufferBlocks build → ActiveTextBlock::push_str (styled/syntax layout per diff)
• ~0.9 GB — LocalDiffStateModel::load_diffs_for_current_repo → get_file_diff → parse_diff_hunks
• ~0.2 GB — CodeReviewView::build_view_state_for_file_diffs (a CodeEditorView + CommentEditor per file)

diff_state_against_head / diff_state_against_specific_branch enumerate all changed + untracked files (git status --untracked-files=all) and, for each, fully parse the diff and retain the base file content in an in-memory Vec<FileDiffAndContent>; the view then builds a CodeEditorModel + buffer per file. For a repo with a large untracked tree (e.g. a non-gitignored node_modules), this materializes tens of thousands of files at once — driving the multi-GB spike.

Fix

Add two aggregate caps in diff_size_limits.rs and enforce them in both enumeration loops:

• MAX_TOTAL_DIFF_FILES = 2000 — max files whose full diff + content we materialize
• MAX_TOTAL_DIFF_BYTES = 256 MB — max cumulative (parsed hunk text + base content) footprint

Once either cap is exceeded the loop stops materializing further files. The cheap aggregate metadata path (diff_metadata_against_specific_branch) is untouched, so the file-count/stat badges still reflect the true totals — only the fully-rendered editor state is bounded.

This is the "cap total processed files / cumulative diff bytes" follow-up explicitly called out in APP-4827, and it targets the ~5 GB editor-materialization facet that the per-file guard in #13393 does not cover.

Testing

• I have manually tested my changes locally with ./script/run

Added unit tests for the new approx_file_diff_bytes helper (diff_size_limits_tests.rs) and a compile-time invariant that the aggregate byte budget exceeds the per-file limit. cargo check, cargo clippy -p warp --tests (0 warnings), and the new tests all pass.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

CHANGELOG-BUG-FIX: Fixed a multi-GB memory spike when opening code review in repositories with very large untracked file trees (e.g. a non-gitignored node_modules).

---

Conversation: https://staging.warp.dev/conversation/90209902-7540-40fd-9fb4-da4a5dbd6820
Run: https://oz.staging.warp.dev/runs/019f3469-5051-7c7b-b2c5-59e25419b3de
Plans:

• APP-4827

This PR was generated with Oz.

[warp-agent-staging]

Heads-up from a live recurrence: Sentry event 021d3fb1803e4e0da9c42572a04febd7 (18.9 GB live, stable v0.2026.07.29.09.05) has ~4.73 GB in parse_diff_hunks DiffLine/DiffHunk allocations aggregated across many under-MAX_DIFF_SIZE files — the facet this PR bounds.

approx_file_diff_bytes counts only line.text.len(), but each retained line also costs a 64-byte DiffLine plus its own String allocation. For short-line content (minified/generated files, the workload in these events) that undercounts real heap by roughly 80x, so a 256 MB accounted budget can still admit >10 GB. Adding a per-line overhead term to the estimate would make MAX_TOTAL_DIFF_BYTES bound what it's named for.

Context: #15225 bounds the per-subprocess capture on the same path, so the two are complementary — under-budget files still parse and aggregate-retain after it lands.

Responding as wilson: Open session · View factory task