Summary
PR #1118 bounds server memory for large untracked files: anything over 5 MiB is shown as a binary addition without loading its contents, and freshness fingerprints use size and mtime metadata instead of reading the file.
There is one path that reintroduces the original blowup. The git status panel offers a stage toggle on untracked files. Staging a large file moves it out of ls-files --others and into the tracked diff (git diff HEAD), which has no size guard. Reproduced during review: after git add on a 51 MB text artifact, the server again buffered a 55 MB patch at roughly 240 MB RSS.
This is really an instance of a pre-existing gap rather than a regression from #1118: any huge tracked text file modified in the working tree hits the same unguarded path today.
Possible fixes
- Apply the same size guard to tracked working-tree diffs in
runGitDiff (render oversized tracked changes as binary, same as the untracked path)
- Or refuse or warn on
/api/git-add when the target file exceeds the threshold
- Either way, keep the two runtimes in sync (Bun
packages/server/ and Pi apps/pi-extension/server/); the shared logic lives in packages/shared/review-core.ts
Repro
head -c 51000000 /dev/urandom | base64 > artifact.js in a repo under review (text content so git emits a full text diff)- Open code review, see the file listed as a binary addition (correct, bounded)
- Click stage on it, watch server RSS climb as the tracked diff buffers the full patch
Credit to @kcosr, whose #1118 fixed the untracked side and whose review surfaced this remaining edge.
Summary
PR #1118 bounds server memory for large untracked files: anything over 5 MiB is shown as a binary addition without loading its contents, and freshness fingerprints use size and mtime metadata instead of reading the file.
There is one path that reintroduces the original blowup. The git status panel offers a stage toggle on untracked files. Staging a large file moves it out of
ls-files --othersand into the tracked diff (git diff HEAD), which has no size guard. Reproduced during review: aftergit addon a 51 MB text artifact, the server again buffered a 55 MB patch at roughly 240 MB RSS.This is really an instance of a pre-existing gap rather than a regression from #1118: any huge tracked text file modified in the working tree hits the same unguarded path today.
Possible fixes
runGitDiff(render oversized tracked changes as binary, same as the untracked path)/api/git-addwhen the target file exceeds the thresholdpackages/server/and Piapps/pi-extension/server/); the shared logic lives inpackages/shared/review-core.tsRepro
head -c 51000000 /dev/urandom | base64 > artifact.jsin a repo under review (text content so git emits a full text diff)Credit to @kcosr, whose #1118 fixed the untracked side and whose review surfaced this remaining edge.