Bug in graphQL API? Paginated query between two specific nodes in stargazers list fails

Hi everyone,

I am querying the APIv4 to get a the sequence of times of stargazing events of some repositories.
It works well using pagination with after: and values of endCursor, but I spotted that for one specific repository, rust-lang/rust, the queries fail at a very specific place. (see at the end for exactly where)

The fact that my code works well on the other repositories I tested, including one with >60k stars; along with the specified type of the error (‘INTERNAL’, see below), makes me think that this is a bug on server side.
Example of error message: {'type': 'INTERNAL', 'message': 'Something went wrong while executing your query. Please include `D9FB:5C53:22F5C3D:288A2C1:5FAEFC1D` when reporting this issue.'}

I order by STARRED_AT, tested with ASC and DESC.

Here is some code to reproduce it, using python. Requirements: pip install --pre "gql[all]"

from gql import gql, Client
from gql.transport.aiohttp import AIOHTTPTransport

API_KEY = (put your api key here)
transport = AIOHTTPTransport(url="https://api.github.com/graphql",headers={'Authorization':'token '+API_KEY})

client = Client(transport=transport, fetch_schema_from_transport=True)


def get_query(nb,after,direction='ASC'):
	query = gql('''
query {{
  repository(owner:"rust-lang", name:"rust") {{
    stargazers(first:{0} after: "{1}" orderBy:{{field: STARRED_AT, direction: {2} }}) {{
      pageInfo {{
        endCursor
        hasNextPage
        hasPreviousPage
        startCursor
      }}
      edges {{
        starredAt
        node {{
          login
          name
        }}
      }}
    }}
  }}
}}
	'''.format(nb,after,direction))

	result = client.execute(query)
	print(result)
	print(nb)


for nb in [1,2]:
	get_query(nb=nb,after='Y3Vyc29yOnYyOpO5MjAyMC0wNi0yNVQyMDo0MjoxMCswMjowMADODX1w8Q==',direction='DESC')

# Comment the previous two lines if you want to get past this point, as they trigger the first error

for nb in [1,2]:
	get_query(nb=nb,after='Y3Vyc29yOnYyOpO5MjAyMC0wNi0yNVQxODozMDoyNiswMjowMADODX0_WQ==',direction='ASC')

Both queries fail for ‘after: 2’ but succeed for ‘after: 1’, and we can see that the two extremities of ASC and DESC are consecutive stargazers, on this stargazers page:

The issue happens between the second and third stargazers, around 6pm on June 25th, 2020.

The code error associated with the issue changes every time, but here are examples:

  • for ASC: {‘type’: ‘INTERNAL’, ‘message’: ‘Something went wrong while executing your query. Please include B70F:5C53:22549DB:27CF051:5FAEF59C when reporting this issue.’}
  • for DESC: {‘type’: ‘INTERNAL’, ‘message’: ‘Something went wrong while executing your query. Please include D79C:E4B6:119219D:1455478:5FAEF55A when reporting this issue.’}

My first hypothesis was that an ‘unstarring event’ might interfere with the structure. I tested by starring and unstarring myself the repository, the query went through without problems around the place i should have been, i.e. hypothesis rejected.

If I am missing something/doing something wrong, please tell me. And if the bug is in fact a server-side bug, I hope here is the right place to report it.

Hello @wschuell and welcome to the community.

I tried reproducing the problem you’re describing by using the following query in graphiql:

query ($after: String, $dir: OrderDirection!) {
  repository(owner: "rust-lang", name: "rust") {
    stargazers(first: 100, after: $after, orderBy: {field: STARRED_AT, direction: $dir}) {
      pageInfo {
        endCursor
        hasNextPage
        hasPreviousPage
        startCursor
      }
      edges {
        starredAt
        node {
          login
          name
        }
      }
    }
  }
}

And I was unable to reproduce the problem. I tried to follow your instructions but I’m not certain what the exact failure case is. Can you give a minimal repro, in other words the smallest possible set of instructions that reproduce the behavior you’re seeing as problematic?

Looking forward to digging in deeper.

Hi lee-dohm,
Thanks a lot for your quick reply!

The parameters for your query func are visible in the last lines of my python code – Sorry to have written a min repro in python and not the official graphiql, I should have read more posts to see that it s the standard way to report them here – The query would work everywhere but on this exact spot, in both ASC and DESC.

e.g.: {“dir”: “ASC”,
“after”:“Y3Vyc29yOnYyOpO5MjAyMC0wNi0yNVQxODozMDoyNiswMjowMADODX0_WQ==”}

returns a null between the two stargazers instead of a node, and the error is visible at the end (I put first:3 to limit the output) :

{
  "data": {
    "repository": {
      "stargazers": {
        "pageInfo": {
          "endCursor": "Y3Vyc29yOnYyOpO5MjAyMC0wNi0yNVQyMDowNzoyMyswMjowMADODX1kkA==",
          "hasNextPage": true,
          "hasPreviousPage": true,
          "startCursor": "Y3Vyc29yOnYyOpO5MjAyMC0wNi0yNVQyMDowMDo1OCswMjowMADODX1h4g=="
        },
        "edges": [
          [
            [
              "starredAt",
              "2020-06-25T18:00:58Z"
            ],
            [
              "node",
              [
                [
                  "login",
                  "johnymbr"
                ],
                [
                  "name",
                  null
                ]
              ]
            ]
          ],
          null,
          [
            [
              "starredAt",
              "2020-06-25T18:07:23Z"
            ],
            [
              "node",
              [
                [
                  "login",
                  "h4ck3rgurl"
                ],
                [
                  "name",
                  null
                ]
              ]
            ]
          ]
        ]
      }
    }
  },
  "errors": [
    {
      "type": "INTERNAL",
      "message": "Something went wrong while executing your query. Please include `ABB2:141F:5D22A4:D89437:5FAF0F25` when reporting this issue."
    }
  ]
}

EDIT: I found something, I looked in githubarchive, on BigQuery, with the following syntax:

SELECT actor.login,repo.name,created_at,payload FROM `githubarchive.day.20200625`
WHERE type='WatchEvent'
 AND repo.name='rust-lang/rust'
ORDER BY created_at

(It would bill you ~10GB, and ~140MB if removing the payload from the SELECT)

The result around the time of the issue is weird:

graphql_bug

Two times in a row ‘action started’ for the same user. The issue could also come from the fact that the user apparently does not exist anymore (https://github.com/okureta is a 404)

EDIT 2: I checked other repos starred by the same account, they are also failing right at the time of the corresponding WatchEvent. I tested only two though, but I think it s enough evidence that the issue is probably that the case ‘stargazer is a deleted account’ yields a null instead of not appearing in the list or being dealt with in a different way, e.g. anonymous like the private sponsors, or displaying the login with a [deleted] tag (provided it is still stored somewhere).

Thanks for the parameters and a more clear picture of where the disconnect is.

According to the documentation for the StargazerConnection object, the type of the edges field is [StargazerEdge] or an array of nullable Stargazer objects. This means that null is a valid value in the edges array. For null to be invalid, the type would have to be [StargazerEdge!]. See the Non-Null section of the GraphQL spec for more information.

Since null is a valid value, it appears that the GraphQL API is working as designed? Or am I misunderstanding what the underlying issue is?