fix: report a provider failure when reading pull request files - #132
Draft
HarshMN2345 wants to merge 2 commits into
Draft
fix: report a provider failure when reading pull request files#132HarshMN2345 wants to merge 2 commits into
HarshMN2345 wants to merge 2 commits into
Conversation
getPullRequestFiles() assumed every response body was a list of file records. GitHub checked no status at all, so an authorization, rate limit or gateway response reached array_merge() and raised a TypeError; Gitea and Forgejo checked the status but not the body, and raised the same TypeError on a non-JSON body. Both surfaced as an unexpected 500 rather than a controlled failure. Reading an error payload as a file list is the quieter half of this. GitLab turned one into a single diff with an empty path, and Bitbucket returned no files at all, so a failed fetch was indistinguishable from a pull request that changed nothing. Check the status before the body on GitHub, and require a list of file records everywhere before merging one. Pagination is unchanged. Base now drives these paths from canned responses, since a live forge cannot be made to page or fail on demand. Adapters describe their own page shape; Gogs opts out through the pull request lookup flag it already sets.
Contributor
Greptile SummaryThe PR makes pull-request file retrieval fail explicitly on provider errors or malformed response bodies instead of returning misleading empty results or triggering type errors.
Confidence Score: 5/5The PR appears safe to merge because no blocking failure remains. No blocking failure remains. Important Files Changed
Reviews (2): Last reviewed commit: "style: keep the pull request files comme..." | Re-trigger Greptile |
HarshMN2345
marked this pull request as draft
August 17, 2026 08:29
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
getPullRequestFiles()assumed every response body was a list of file records:GitHub checked no status at all, so an authorization, rate-limit or gateway response reached
array_merge()and raised aTypeError— Appwrite reported an unexpected 500 instead of a controlled failure. Gitea and Forgejo checked the status but not the body, and raised the identicalTypeErroron a non-JSON body (an HTML error page from a proxy decodes to a string).Reading an error payload as a file list is the quieter half, and it does not crash:
{"message": "Bad credentials"}at 200TypeErrorTypeError[{"filename": ""}][][], correctly — its pages are objects[]Both consumers read
filename/previous_filenameoff the result to decide which deployments a push affects, so a failed fetch that returns an empty list looks like a pull request that changed nothing, and the deployments are silently skipped. That failure mode reaches no error tracker at all.Fix
Check the status before the body on GitHub, and require a list of file records everywhere before merging one. Pagination is unchanged in every adapter.
Only GitHub is released today, which is why it is the only one reporting this — not the only one affected.
Test plan
Basenow drives these paths from canned responses, since a live forge cannot be made to page or fail on demand. Each adapter describes its own page shape throughpullRequestFilesPage(); Gogs opts out through the$supportsPullRequestLookupflag it already sets, and Forgejo inherits Gitea's coverage.Four tests per adapter — pagination across two pages, 401/403/404/500, a failure on a later page, and malformed bodies. Reverting
src/alone fails 7 of them, across all five supported adapters, including botharray_merge()TypeErrors. The pagination tests pass before and after, which is what shows paging is untouched.composer lintandcomposer checkare clean.Note for review: these run through
setupAdapter(), so they need the usual credentials or compose stack. I could not bring a forge up locally (Docker daemon unresponsive) and verified the harness with throwaway subclasses that stubsetupAdapter(). CI is the first run through the real path.🤖 Generated with Claude Code