How can I implement pagination in the entries in the following GraphQL query?

[RAFAQAT11]

Select Topic Area

Question

Body

I am trying to figure out how to add pagination, like first & after for the entries.

& Does this query tells all the name regardless of the number?

query {
  repository(name: "<repo>", owner: "<owner>") {
    object(expression: "master:<path>") {
      ... on Tree {
        entries {
          name
        }
      }
    }
  }
}

[LangLangBart]

• GraphQL API is introspective in your case the entries field on the Tree object doesn't take any arguments

{
  __type(name: "Tree") {
    name
    fields {
      name
      args {
        name
      }
    }
  }
}

{
  "data": {
    "__type": {
      "name": "Tree",
      "fields": [
        {
          "name": "abbreviatedOid",
          "args": []
        },
        {
          "name": "commitResourcePath",
          "args": []
        },
        {
          "name": "commitUrl",
          "args": []
        },
        {
          "name": "entries",
          "args": []
        },
        {
          "name": "id",
          "args": []
        },
        {
          "name": "oid",
          "args": []
        },
        {
          "name": "repository",
          "args": []
        }
      ]
    }
  }
}

• where as as an example on the User object the starredRepositories field does take arguments

{
  __type(name: "User") {
    name
    fields {
      name
      args {
        name
      }
    }
  }
}

...
         {
          "name": "starredRepositories",
          "args": [
            {
              "name": "after"
            },
            {
              "name": "before"
            },
            {
              "name": "first"
            },
            {
              "name": "last"
            },
            {
              "name": "ownedByViewer"
            },
            {
              "name": "orderBy"
            }
          ]
        },
...

---

Does this query return all names regardless of the number?

Yes, it appears to return all names, but it may fail if the query takes too long. According to a talk I watched, the query will fail if it exceeds 10 seconds (mentioned at the 17-minute mark).

• Ref: Rea Loretta (15/Dec/19) - Advanced patterns for GitHub's GraphQL API

Here is an example of a query that will likely fail due to a timeout.

• Repo: itsnebulalol/sdks

{
  repository(owner: "itsnebulalol", name: "sdks") {
    object(expression: "@:macOS14.0.sdk/usr/share/man") {
      ... on Tree {
        entries {
          name
          object {
            ... on Tree {
              entries {
                name
              }
            }
          }
        }
      }
    }
  }
}

{
   "data": null,
   "errors":[
      {
         "message":"Something went wrong while executing your query. This may be the result of a timeout, or it could be a GitHub bug. Please include `DE86:3A75B8:15565:3FEB8:653B2DE0` when reporting this issue."
      }
   ]
}

---

If you need to paginate the entries field, you would need to wait for GitHub to provide this functionality. In the meantime, you can only modify the JSON response yourself. Hopefully, the query will be successful.

[RAFAQAT11]

Thanks @LangLangBart,

This method also doesn't support pagination

octokit.rest.repos.getContent({
  owner,
  repo,
  path,
});

[tmuldoon]

I have a similar query which fails regularly (seemingly due to a timeout) and I'm wondering if GitHub has made any recent improvements regarding the pagination of the entries field. My query...

  query {
    repository(owner: "<owner>", name: "<name>") {
      object(expression: "HEAD:") {
        ... on Tree {
          entries {
            name
            type
            object {
              ... on Tree {
                entries {
                  name
                  type
                }
              }
            }
          }
        }
      }
    }
  }

Assuming no, I am thinking of a simpler query to get the 1st layer and subsequent queries to get the 2nd layer (for each 1st layer element). Testing proves that it will work but at a cost of performance (700+ entries in total).

Thanks in advance, Tom