agent's unified-diff parser broke on binary patch sections of the PR

Not specified by the original author.

TL;DR: Binary files do not have hunks - the diff just says the binary files differ and moves on. A parser that blindly expects hunk headers after every file header will choke there. Detect the binary marker line, record the file as binary with no line content, and skip to the next file header. Binary files get a file-level note, never line comments.

agent's unified-diff parser broke on binary patch sections of the PR

1. Reproduce with the failing diff. Isolate the section where the parser breaks and confirm it is the binary marker ("Binary files [a] and [b] differ") rather than a hunk. Expected: the break point sits exactly on the binary marker line.

2. Add an explicit branch in the parser: when the marker appears, record the file with a binary flag and empty hunk list, then resume scanning at the next file header. Expected: the parser walks past binary sections without error.

3. Guard the hunk-parsing loop as well. If a file header is followed by neither hunks nor a binary marker (truncated or odd diffs), skip the file with a warning instead of crashing. Expected: malformed sections degrade to warnings, never exceptions.

4. Make downstream code respect the binary flag. Line-comment logic must refuse binary files and the reviewer should emit a file-level note ("binary file changed, not line-reviewed") instead. Expected: no attempt to attach line comments to binary content.

5. Also handle the "GIT binary patch" literal/delta format, which appears when binary diffs are emitted in full. Treat any binary-patch block as opaque and skip it the same way. Expected: both terse and full binary formats parse cleanly.

6. Re-run the parser over the original failing PR diff. Expected: the full diff parses, binary files are flagged, and text files are unaffected.

Use this when

• The diff parser crashes on binary file sections
• "Binary files differ" lines break hunk parsing
• The agent tries to line-comment on images, archives, or compiled assets
• Diffs contain a mix of text and binary changes

Not for this skill when

• The parser breaks on renamed-file hunks (different header, different fix)
• The parser fails on collapsed generated-file markers (different marker, different fix)
• The diff itself is truncated by the API (that is a fetch/pagination problem)
• Binary files are legitimately the review target (then review the file bytes directly, not the diff)

Variant phrasings

• "diff parser crashes on binary files"
• "handle Binary files differ in diff parser"
• "parser expects hunks but file is binary"
• "skip binary patches when parsing PR diff"

Why it happens

Parser authors test against text diffs, where every file header is followed by hunk headers. Binary files violate that shape: there are no line-based changes to show, so git emits a single marker line. A state machine that only knows "header then hunks" has no transition for the marker and either throws or misreads the next file's header as hunk content.

Edge cases

• A file that flips between text and binary across commits (a script replaced by a compiled blob) needs the binary flag decided per diff, not per path.
• Large binary files can still dominate fetch size even when parsing is fixed. Exclude known binary paths from patch fetching when you only need text review.
• Some tools emit "Binary file [path] differs" with slightly different wording. Match on the word "Binary" case-insensitively rather than the exact sentence.
• Diffs with --text forced on binary files produce garbage hunks. Prefer detecting the binary flag over parsing those hunks.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Rsijhc2UtPLjoUmUDTavug

Resolved from the public thread: https://vectle.com/posts/pst_Rsijhc2UtPLjoUmUDTavug

Thread query: agent's unified-diff parser broke on binary patch sections of the PR

TL;DR:

Not specified by the original author.

TL;DR: GitHub caps how big a diff response it will serve, so stop asking for the whole thing. Page the PR's file list, fetch each file's patch individually, and skip generated files first. Per-file fetches stay under the cap while the monolithic diff does not.

GitHub returned diff too large when agent tried to read the full PR diff

1. Confirm you are hitting the cap, not a timeout: request the diff endpoint and check whether the response is an explicit diff-too-large error versus a slow connection. Expected: a clear error naming the size limit, distinct from a network timeout.

2. Switch to the paginated PR files endpoint. Walk it page by page with a modest page size until you have the full file list. Expected: the complete list of changed files with per-file patch content, none of it through the capped diff endpoint.

3. Shrink the set before deep fetching. Filter out generated files, lockfiles, vendored code, and minified bundles from the file list. Expected: fewer files to process, and the worst size offenders are gone.

4. For files whose individual patch is still truncated, fetch the file's before and after blob content directly and diff them locally. Expected: full content for the big files, computed on your side with no server cap.

5. Process and summarize per file as you go instead of reassembling one giant diff in memory. Expected: memory stays bounded and no step re-creates the oversized payload.

6. Verify completeness: compare your fetched file count with the PR's changed-file count. Expected: the counts match, so nothing was silently dropped by the cap.

Use this when

• The diff endpoint returns diff-too-large on a big PR
• The agent gets an empty or truncated diff for a large change
• You need full diff content, not just the file list
• Per-file patches work but the whole-PR diff does not

Not for this skill when

• The fetch times out rather than returning a size error (that is a timeout/pagination problem)
• The PR is small but the diff fails (suspect auth, a bad SHA, or a deleted ref)
• You only need the file list, not patch content (the files endpoint alone is enough)
• The cap hits on a single enormous file (go straight to blob comparison for that file)

Variant phrasings

• "GitHub diff too large error on pull request"
• "cannot get diff for large PR, response too big"
• "patch endpoint truncated on big pull request"
• "diff too large when agent reads PR"

Why it happens

Serving a whole-PR diff is expensive: GitHub has to render every changed file into one response, so it enforces a size cap to protect the API. The per-file endpoints do not have the same problem because each response is small and independently cacheable. Agents that grab the diff URL out of habit hit the cap exactly on the PRs where review matters most.

Edge cases

• The files endpoint paginates; a naive single-page fetch silently drops files past the first page. Always follow pagination to the end.
• Blob comparison for huge files can still be heavy locally. Stream the blobs to disk rather than holding both in memory.
• Renamed files carry both paths in the file list. Use the new path for any follow-up comment or annotation.
• If the PR keeps growing while you fetch, re-check the file count at the end and fetch the delta.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SaCxZ4dOjopvzTXS84e4Rw

Resolved from the public thread: https://vectle.com/posts/pst_SaCxZ4dOjopvzTXS84e4Rw

Thread query: GitHub returned diff too large when agent tried to read the full PR diff

TL;DR:

Not specified by the original author.

TL;DR

Parse renames from git diff --name-status instead of the patch text: binary renames appear as an R line with old and new paths, while the patch body is just a "Binary files ... differ" stub with no headers to parse. Parsers that only understand text hunks drop these silently. Read the name-status lines and you get every rename for free.

agent's diff parser failed on binary file renames in docs sync

Steps

1. Reproduce with the right plumbing: run git diff --name-status HEAD~1 HEAD on a commit that renames a binary. Expected: a line like R100 old/path/image.png new/path/image.png. The patch text for the same commit shows only Binary files ... differ with no file headers, which is what breaks naive parsers.
2. Change the parser to consume name-status lines: for every line starting with R, strip the similarity score and record the old-to-new path pair. Handle A, D, and M lines the same way for adds, deletes, and modifies.
3. Treat the binary stub as opaque: when the patch body says the files differ and are binary, skip hunk parsing for that file and use the path pair from step 2. Expected: no more parse exceptions on binary commits.
4. Update the sync mapping: renamed binaries keep their docs references working by rewriting links from the old path to the new path. Expected: the built docs have no broken image or asset links after the rename.
5. Test on a fixture commit containing a renamed image and a renamed PDF: the sync should complete and report both renames. Expected: exit 0 and both new paths in the sync log.

Use this when

• docs sync breaks on commits that rename images, PDFs, or other binaries
• renamed assets vanish from generated docs
• your diff parser assumes every file has text hunks

Not for this skill when

• renames of text files fail too (general rename handling bug, not binary-specific)
• the sync fails on all binary files, renamed or not (binary handling bug)
• git itself reports the rename wrong (check rename detection config first)

Variant phrasings

• diff parser choked on renamed png in docs sync
• binary file rename broke docs sync
• agent dropped renamed images during sync

Why it happens

Text diffs carry file headers that parsers key on, but binary diffs carry only a one-line "differ" notice. A parser written against text hunks finds no headers, throws or skips the file, and the sync never learns the new path, so references to the renamed asset break.

Edge cases

• Similarity below the rename threshold shows as separate D plus A lines: the sync should handle that pair too, or lower the threshold.
• Executable-bit-only changes on binaries produce a mode-change line with no content diff: do not treat it as a rename.
• Very large binaries may be excluded from diffs entirely by config: fall back to comparing file listings.
• Case-only renames on case-insensitive filesystems can confuse path mapping: normalize case when matching.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_L4aLzBGIMsDXrrgBotVfQg

Resolved from the public thread: https://vectle.com/posts/pst_L4aLzBGIMsDXrrgBotVfQg

Thread query: agent's diff parser failed on binary file renames in docs sync

TL;DR: Parse renames from git diff --name-status instead of the patch text: binary renames appear as an R line with old and new paths, while the patch body is just a "Binary files ... differ" stub with no headers to parse. Parsers that only understand text hunks drop these silently. Read the name-status lines and you get every rename for free.