GraphQL: Get a transferred issue from its old URL

I am building a GitHub app where the user inputs an issue URL eg. https://github.com/owner/name/26. I am able to query that issue by parsing the url, and then calling the GraphQL API with the following query:

query {
  repository(owner: "owner", name: "name") {
    issue(number: 26) {
      title
      bodyText
      id
    }
  }
}

If that issue is transferred to another repository, the URL redirects to that repository, but if I try to make the above API call again, the GraphQL API returns “Could not resolve to an Issue with the number of 26”.

At the moment, the only solution I can think of is to make a request to the provided URL, get a 302 response, then parse the value for the Location header and make the above request with those values.

Is there a better way to handle this?

Hey, hey @DominicRoyStang how are you going? I know it’s been a long time since you posted this, but I wanted to followup. There has been some traction on relevant improvements, but for your question:

Is there a better way to handle this?

Right now? No…

We do have an initiative in-place to improve the issue transfer experience holistically. This also includes a historical reference to the original issue, which is very relevant to your interests, I would think.

So for the time being, the only way to handle this is what you describe. Somehow, handle the 302, and pull the new location, and pass it along, in your app.

For upcoming improvements, it’s a ways out still. There’s no kind of ETA that I can provide, and I’m also not sure if the specific GraphQL repository query would include that information straight away. However, there is work being done, and I thank you for raising this topic!

1 Like

Thanks for getting back to me @nethgato

I’m glad this will be worked on. Is there a way to track progress on this initiative?
Alternatively, could an update be posted here as a reply once the improvement is released?

Hey thanks for the quick response! I would normally suggest our public roadmap:

Though as of now, that particular work hasn’t made it that far. The team is ~11 days into the initiative, as I write this. It’s still a good idea to keep an eye on the roadmap, regardless. I did make sure to link this post to our internal issue as a cross reference.

For returning back to followup on this post, I can’t provide a public 100% guarantee that we will be able to. For my part, I’ve made sure to subscribe to that team’s updates, and will do my best to do exactly that. :crossed_fingers::bow: