How GitHub’s Diff Limit Broke Our Linting Workflow (And How We Fixed It)

Recently, we hit an unexpected issue while running our Go linter (golangci-lint) in a GitHub Actions workflow. The linter started failing, not because of new issues introduced in the code—but because it couldn’t even get the full diff from GitHub.

Here’s a breakdown of what went wrong, why it happened, and how we fixed it.

The Setup

We recently added a golangci-lint check to a large Go repository. This repo uses vendored dependencies (/vendor folder), and as expected, the codebase has accumulated a fair share of historical linting issues over time.

Since we didn’t want to fix all those legacy lint errors right away, we configured the linter to only run against changed files on pull requests.

This worked fine—until it didn’t.

The Problem

After a dependency update, our pull request touched more than 300 files, including vendor files. Suddenly, our GitHub Actions workflow started failing with an error like this:

Sorry, the diff exceeded the maximum number of files (300). Consider using 'List pull requests files' API or locally cloning the repository instead.

‍

GitHub’s API limits the number of files you can retrieve in a diff to 300. Our workflow relied on fetching the diff to determine which files to lint. Since the list was truncated, the linter ended up scanning the entire codebase instead of just the changes.

That meant it found all the old linting errors in untouched files—errors we had deliberately ignored until now. Naturally, the workflow failed.

The Fix

To get around the 300-file diff limit, we modified our GitHub Action workflow to:

1. Use GitHub’s "List pull request files" API, which supports pagination and lets you fetch the full list of changed files in batches.
   
   
2. Manually pass the list of changed files to golangci-lint using its --new and --new-from-rev options (or simply filter the list via script).
   
   
3. Avoid triggering a full-project lint, which would have failed due to legacy issues.
   
   

Once we made these adjustments, the workflow ran as expected—only checking the files we actually touched in the PR. No more surprise failures.

Takeaways

• GitHub’s diff API silently truncates at 300 files, which can break automation that relies on complete diffs.
  
  
• Large PRs that touch vendored files or regenerate code can easily hit this limit.
  
  
• If you’re linting only changed files, make sure your workflow accounts for this limit and uses the paginated List pull request files API when needed.
  
  

Adding linters to legacy codebases? Always plan for a “new files only” mode—or be ready for a long cleanup session.