New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GitHub Pull Request diff API responds with 406 — diff too large #1696
Comments
Seeing similar issues with PRs with lots of files. We have an automation to sync assets from designers and it had around 1200 files changed. Failed in the same way but with a different message about to many files. |
Hi @haya14busa , Encountering the same issue as #1696 with the reviewdog action failing due to GitHub's new diff size limit. This is impacting our large PR workflows severely. Any known workarounds or planned updates to address this? Appreciate your efforts on reviewdog. Thanks. |
Related issue: |
Does anyone provide feedback to GitHub? |
No work around yet. Might have to remove reviewdog from our flows if some solution isn't found. |
https://github.com/massongit/action-golangci-lint/actions/runs/8465852986/job/23193377688?pr=2
If your pull requests have a large number of files as above, you may be able to use the list pull requests files API ( https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#list-pull-requests-files ) instead of the get a pull request API. |
It seems possible to work around this using the PR files API in many cases, but it's not a drop-in replacement. The files JSON response still returns the patch text, but it's not in the same multi-file format that the other endpoint returns. The docs claim that the files API can return results in the same Is there a reason that we need to be fetching this diff from GitHub instead of just using git to generate it locally from the repo? Is there an existing DiffService that already does this that we could use as fallback? |
This hasn't resolved the issue for us in GitHub Actions.
I'm guessing this has something to do with the shallow clone it does at checkout. Do we need to fetch head with /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +71ca3938e27ea342224c721a0bfdd16db4e908d6:refs/remotes/pull/4248/merge |
Same here. After the patch we started to face this other issue. In our case we had to adjust the Git checkout command in our GitHub action job to use a fetch depth of 0 (as opposed to the default of 1). |
While setting I'm not a git expert, but it seems that if we did a fetch like this, using GitHub default env vars, the necessary branch would be available for the subsequent /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 $GITHUB_HEAD_REF https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables |
Do the related actions need bumping ? eg. reviewdog/action-shellcheck etc? |
@dprotaso it seems that some are on the right version https://github.com/reviewdog/action-yamllint/blob/master/Dockerfile#L3, others not https://github.com/reviewdog/action-shellcheck/blob/master/action.yml#L63. |
@massongit thanks for the two PRs! It's working great for us now |
Yeah it's still happening - do folks have any suggestions here? reviewdog: post failed for woke: fail to parse diff: GET https://api.github.com/repos/knative/serving/pulls/15066: 406 Sorry, the diff exceeded the maximum number of lines (20000) [{Resource:PullRequest Field:diff Code:too_large Message:}] |
Currently, this issue is only resolved when the reporter is |
- [x] depends on: reviewdog/action-suggester#52 This reverts #12280 after the upstream fix reviewdog/reviewdog#1696 has propagated to reviewdog/action-suggester@v1. This should happen when https://github.com/reviewdog/action-suggester/releases has a release that uses [v0.17.4](https://github.com/reviewdog/reviewdog/releases/tag/v0.17.4) or higher. When this happens, rebase this pull request and re-trigger to see that it doesn't fail with the 300 dummy files. Then remove the dummy files and merge this pull request. Co-authored-by: Moritz Firsching <firsching@google.com>
- [x] depends on: reviewdog/action-suggester#52 This reverts #12280 after the upstream fix reviewdog/reviewdog#1696 has propagated to reviewdog/action-suggester@v1. This should happen when https://github.com/reviewdog/action-suggester/releases has a release that uses [v0.17.4](https://github.com/reviewdog/reviewdog/releases/tag/v0.17.4) or higher. When this happens, rebase this pull request and re-trigger to see that it doesn't fail with the 300 dummy files. Then remove the dummy files and merge this pull request. Co-authored-by: Moritz Firsching <firsching@google.com>
- [x] depends on: reviewdog/action-suggester#52 This reverts #12280 after the upstream fix reviewdog/reviewdog#1696 has propagated to reviewdog/action-suggester@v1. This should happen when https://github.com/reviewdog/action-suggester/releases has a release that uses [v0.17.4](https://github.com/reviewdog/reviewdog/releases/tag/v0.17.4) or higher. When this happens, rebase this pull request and re-trigger to see that it doesn't fail with the 300 dummy files. Then remove the dummy files and merge this pull request. Co-authored-by: Moritz Firsching <firsching@google.com>
We've started seeing several of our GitHub actions builds with reviewdog fail this morning because the GitHub API is returning a 406 error code on diffs larger than 3,000 lines. This seems to be new GitHub API behavior because the same version of reviewdog worked was passing on these same PRs three days ago.
The error message currently has no relevant Google results. Searching around on GitHub, I only find one mention of
Code:too_large
withfield: diff
anywhere, and it's from another reviewdog user today: platformsh/platformsh-docs#3885 (comment)We've seen this both when running from actions like https://github.com/reviewdog/action-brakeman and from custom actions that invoke reviewdog manually.
An example reviewdog error when running with
reviewdog -name=Hadolint -reporter=github-check -efm='%f:%l %m' -level=warning
:The API response from GitHub:
The text was updated successfully, but these errors were encountered: