Following moved repositories with GraphQL


#1

When browsing GitHub, or using API v3, if you look for a moved or renamed repository, you get redirected to the new location. v4 gives the new location in both the Response Headers, and the JSON response body. (see v3 below)

In GraphQL, the search for the same moved repository simply returns a 404, with no guidance as to the new location. (see v4 below)

This seems to be a bug, at least as I read the docs. Is there a workaround?

v3

$ http https://api.github.com/repos/mozilla-releng/services
HTTP/1.1 301 Moved Permanently
...
Location: https://api.github.com/repositories/51109207
Server: GitHub.com
Status: 301 Moved Permanently


{
    "documentation_url": "https://developer.github.com/v3/#http-redirects",
    "message": "Moved Permanently",
    "url": "https://api.github.com/repositories/51109207"
}

v4

$ http -v PUT https://api.github.com/graphql Authorization:"token $(curToken)" query='{ "query": "query { repository(owner:mozilla
-releng, name:services) { nameWithOwner }}" }'
PUT /graphql HTTP/1.1
Content-Type: application/json
Host: api.github.com

{
    "query": "{ \"query\": \"query { repository(owner:mozilla-releng, name:services) { nameWithOwner }}\" }"
}

HTTP/1.1 404 Not Found
Date: Tue, 24 Jul 2018 20:22:57 GMT
Server: GitHub.com
Status: 404 Not Found

{
    "documentation_url": "https://developer.github.com/v4",
    "message": "Not Found"
}

#2

Based on lack of response, it sounds like GraphQL does not provide any help in following a renamed repository.

My best guess then, is that anything that wants to deal with moved or renamed repositories, should:

  • record the id at time of first lookup
  • make all requests using the id (not name)
  • compare old name to new name if detection of the move or rename is desired.

#3

:wave: @hwine,

Apologies for the delay in responding. As you noted, we don’t have a great way to offer information that a repository has moved in GraphQL. This is something that we’ve talked about internally, but don’t have a great solution for right now.

As you suggested, recording the id and making subsequent requests based on the node(id:$id) is the best option right now.

I’ll link up this post to our internal thread about this issue so that when we have more to share, we’ll update this too.