Questions regarding the Node ID migration

Around 3 months ago there were an official blog post regarding migration to the new GraphQL Node IDs.

There were no more details since then, but we accidentally encountered the new Node ID in one of the GraphQL responses. It might be a bug, but in any case it’s clear that the transition has started.

There are still a few questions unanswered, though:

  1. When we could expect the first rollout of the new IDs format for one of the node types?
  2. What will be the migration path for existing data? Will there be any tooling that can translate old IDs into new one offline (without requesting all the data again)?
  3. Is there any chance the ID format will be documented? The format was changed for efficiency reasons, and those reasons can be extended to the community, not only Github itself. On our side we’d like to see at least a way to determine the node type by looking at the ID, as Github API does internally.
2 Likes

Hey @dennwc :wave:

Thanks so much for starting this conversation! Right now, the answers to your questions are incomplete. The efforts to update our various APIs with this updated format are ongoing.

I did reach out to the project manager overseeing these tasks, and I want to forward what information I can.

  1. When we could expect the first rollout of the new IDs format for one of the node types?

Unfortunately, we can’t provide any firm dates, but I definitely understand the interest! There are some objects that have had this work completed, but end users should have a seamless experience for the time being. Old ID formats will continue to be accepted, and if/when new IDs are noticed, they should not block any existing workflows.


  1. What will be the migration path for existing data? Will there be any tooling that can translate old IDs into new one offline (without requesting all the data again)?

Again, I can’t speak to the timeline as the forecasted timeline we projected has been pushed back. Though yes, there will be migration tools, and while we are in a transitional state, folks using legacy IDs will still function and be provided with the deprecation notice until the migration is completed.


  1. Is there any chance the ID format will be documented? The format was changed for efficiency reasons, and those reasons can be extended to the community, not only Github itself. On our side we’d like to see at least a way to determine the node type by looking at the ID, as Github API does internally.

Yes! We will update our docs page for Global Node IDs here. Though I think the intent of this question is to document more than just the format that users will expect, but to perhaps expose our internal API usage? Maybe I misunderstand, but for that, I couldn’t speak to it. It’s doubtful that we will be publishing say, how our internal APIs are leveraging this new ID format.


Going forward, we are still planning to issue a new blog post to document the progress made, and what to expect in the future. I’m not going to say that updates are coming “soon,” but after my discussion with the PM, I want to reiterate that efforts are ongoing, even as I type this.

Please feel free to keep the conversation going and maybe consider subscribing to the blog’s RSS feed:

1 Like

Thanks, it answers most of it, but I wanted to clarify this part:

Though I think the intent of this question is to document more than just the format that users will expect, but to perhaps expose our internal API usage? Maybe I misunderstand, but for that, I couldn’t speak to it. It’s doubtful that we will be publishing say, how our internal APIs are leveraging this new ID format.

No, sorry, we are not expecting to know the internals of the API itself, but rather at least some information that can be decoded from those new IDs. We are mostly interested in:

  • Getting node type directly from node ID without querying GraphQL.
  • Getting SHA and repository ID from Commit node IDs (and back).
  • Getting some “primary key” for other nodes.

The reason I mentioned the Github API internals is because ID format is designed in a certain way to contain enough information for the backend to locate the node of any type. And I believe the information about this format/encoding can be useful for other developers like us as well. Hence the question regarding the documentation. This is an optimization we already use to reduce request rates to GraphQL API with the current node ID format.

2 Likes