GraphQL pagination breaks on partial results

[laughedelic]

Describe the bug

►  gh --version
gh version 2.14.3 (2022-07-26)
https://github.com/cli/cli/releases/tag/v2.14.3

I'm trying to use GraphQL API to fetch repositories with a certain file, including its content. The file is not expected to be present in every repository, I'm only interested in those where it exists. GraphQL API returns partial results (replacing the file field with null) in such cases and a list of errors with the reason. As I understand from this article: https://hasura.io/blog/graphql-nulls-cheatsheet/#nulls-in-the-response it's normal and shouldn't be considered a failed request. So I expect gh to keep querying subsequent pages and accumulate results and errors. Instead, it fetches the first page and stops, as if the query has failed.

Steps to reproduce the behavior

An example query:

gh api graphql \
  --paginate \
  -f query='query ($endCursor: String) {
    organization(login: "...") {
      repositories(
        first: 10
        after: $endCursor
      ) {
        pageInfo {
          endCursor
          hasNextPage
        }
        nodes {
          url
          object(expression: "HEAD") {
            ... on Commit {
              file(path: ".github/dependabot.yml") {
                object {
                  ... on Blob { text }
                }
              }
            }
          }
        }
      }
    }
  }'

Result:

{
  "data": {
    "organization": {
      "repositories": {
        "pageInfo": {
          "endCursor": "Y3Vyc29yOnYyOpK5MjAyMi0wNy0yMF...",
          "hasNextPage": true
        },
        "nodes": [
          {
            "url": "https://github.com/org/repo1",
            "object": {
              "file": {
                "object": {
                  "text": "version: 2\nupdates:\n  - package-ecosystem: \"github-actions\"\n    directory: \"/\"\n    schedule:\n      interval: \"daily\""
                }
              }
            }
          },
          {
            "url": "https://github.com/org/repo2",
            "object": {
              "file": null
            }
          }
        ]
      }
    }
  },
  "errors": [
    {
      "type": "NOT_FOUND",
      "path": [ "organization", "repositories", "nodes", 1, "object", "file" ],
      "locations": [ { "line": 18, "column": 15 } ],
      "message": "Could not resolve file for path '.github/dependabot.yml'."
    }
  ]
}

I redacted results for brevity. Notice "hasNextPage": true.

You can see that the response data contains some results with the file's contents and some results with "file": null. And every null case is explained in the errors array. These errors are not fatal and shouldn't fail the query.

Expected vs actual behavior

• Expected: get all pages with partial results from each query accumulated in the .data.organization.repositories.nodes array and all errors accumulated in the .errors array.
• Actual: gh stops after the first page

Relevant links

• https://hasura.io/blog/graphql-nulls-cheatsheet/#nulls-in-the-response
• https://github.com/octokit/graphql.js#partial-responses
  • another example here with an explanation

Potentially related issues

• Merge JSON responses from gh api #5652
• Print HTTP errors on stderr in api command #1115

[mislav]

Thanks for the detailed report! Absolutely agreed that GraphQL errors are not always fatal and that in this case pagination should continue even if there were some partial GraphQL errors. This is perhaps indicative of gh api possibly being over-zealous with error handling and that we should possibly add an opt out mechanism so that the consumer itself can decide how to handle errors, particularly those from GraphQL. But, as a stopgap fix, we could just disable GraphQL error processing in --paginate mode and return all server results verbatim.

[laughedelic]

Thanks for the feedback!

as a stopgap fix, we could just disable GraphQL error processing in --paginate mode and return all server results verbatim.

this sounds good 👍