[Bug]: PR Code tab shows empty file diffs when GitHub omits patches on large API pages #31404

ℹ️ Written by GPT-6.1 Sol on behalf of Andrei Shenets

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web; packages/source-control-github

Summary

The PR Code tab can list changed text files without addition/deletion counts and expand to no content. GitHub's paginated files API can omit both patches and accurate counts for larger pages. T3 requests 100 files per page and silently treats zero-count, patchless entries as complete empty diffs.

Steps to reproduce

1. Open a GitHub PR with a sufficiently large set of text changes in T3's PR Code tab. The observed PR changes 351 files, so GitHub rejects the whole-diff request with HTTP 406 and T3 falls back to the paginated files API.
2. Inspect file rows without counts and try expanding them: they have no diff content.
3. Compare the files API responses using per_page=100 (T3's current setting) and per_page=30. Follow all pages and match entries by filename, because changing page size changes each file's page.

The original repository is private; identifiers and content are intentionally omitted. The following is an anonymized, minimal actual response shape replayed through decodePullRequestFilesJson and the installed Pierre patch parser:

[{"filename":"example.cs","status":"added","additions":0,"deletions":0}]

The actual file is nonempty UTF-8 text (3,688 bytes; local Git reports 132 added lines). The decoder produces a header-only patch, truncated: false, and omittedFileStats: []. Pierre produces one file with zero hunks. With per_page=30, GitHub returns the same file with additions: 132 and a real patch; the same decoder/parser produces one hunk.

Across the observed PR, per_page=100 returned 51 patchless files, 49 also reporting zero counts. With per_page=30, all 49 incorrect zero-count entries recovered. Four large-file patches remained omitted, but their counts were present.

Expected behavior

Changed text files remain reviewable when GitHub omits a patch. Missing patches are distinguished from genuinely empty changes and pure renames. Recoverable content should be loaded on demand; unrecoverable content should have an explicit unavailable state rather than an apparently empty file.

Actual behavior

Rows appear without +/- counts, and expanding them shows no content. Missing-patch detection only records an omission when the supplied additions/deletions are nonzero, so the incorrect zero-count responses escape detection entirely. Larger files with omitted patches also need a content fallback; smaller API pages alone do not resolve that case.

Impact

Major degradation: parts of a large PR cannot be reviewed inside T3.

Version and environment

• Reproduced through the decoder/parser in checkout 8b44f42b14 on Windows, Node.js 26.12.1.
• The relevant GitHub API adapter, JSON decoder, and PR Code tab files are byte-for-byte identical to upstream main at 337c5858c33bc7f8f6dfd391a2c279fa0f7e4d17; this is not fork-specific code.

Relevant source and possible fix

• DIFF_FILES_PAGE_SIZE = 100; whole-diff fallback.
• toFilesPatch only marks patchless entries as truncated when counts are positive.
• Use smaller API pages (30 was verified here), and handle omitted patches independently of their supplied counts, with an on-demand content fallback or explicit unavailable state.

Related prior report

OpenJDK Skara #1302 documents GitHub omitting patches with larger page sizes and separately omitting oversized individual patches. This is related API behavior, not a claim that its exact threshold explains every omission here.