[GraphQL] Add available versions query to service config

[stefan-mysten]

trafficstars

Description

Adds available versions query to the service config. This is a best effort solution, as it has to try to query that service with a few combinations of versions (this/prev year + months 1,4,7,10).

It assumes that the queries are sent to hostname or to hostname/graphql, and only tries these two paths. Unclear yet on how fancy we want to be here.

For parsing the header version, I think this should be done through Version type, implementing the FromStr for it. However, due to the Version being only static str, I could not figure it out.

Test plan

Existing tests. Manual query on local instance.

{
  serviceConfig {
    availableVersions
  }
}

{
  "data": {
    "serviceConfig": {
      "availableVersions": [
        "2024.7-2e03bca82d63"
      ]
    }
  }
}

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

• [ ] Protocol:
• [ ] Nodes (Validators and Full nodes):
• [ ] Indexer:
• [ ] JSON-RPC:
• [ ] GraphQL:
• [ ] CLI:
• [ ] Rust SDK:

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 9, 2024 7:55pm

3 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		May 9, 2024 7:55pm
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		May 9, 2024 7:55pm
sui-typescript-docs	⬜️ Ignored (Inspect)	Visit Preview		May 9, 2024 7:55pm

[emmazzz]

I wonder if it's possible to just hard code the versions in the code and make sure we update it as we deprecate old version or start up new versions, if we drop the SHA?

[amnn]

We cannot hardcode it in the GraphQL codebase, because RPC providers may run different deployments (may choose to support more or fewer versions of the service). A provider whose business it is to run RPC may support many more versions, whereas someone who is running RPC for their own app to use may support only the version their app needs. In both cases the deployment needs to advertise a different list of supported versions than the public good RPC. This is why it's conceptually part of the service configuration.

Even without this requirement , hard-coding versions would be difficult to work with because it means that every time we update the versions we support, we would need to write 4 PRs -- one for the configuration, and one for each running version of the service -- which is quite a bit of effort and leaves room for error (forgetting to update one version and then it's advertising something different).

I would say though that this is not the highest priority item, so if this will take longer than envisioned to build out, we should park this in the backlog and come back to it once we have gone through the performance work, as part of our long-term release process workstream.

[stefan-mysten]

@amnn I did some changes. Not very happy with the need to push the version into the context data for each query. The alternative is to add the version as a field on the ServerConfig type.

[vercel[bot]]

@stefan-mysten is attempting to deploy a commit to the Mysten Labs Team on Vercel.

A member of the Team first needs to authorize it.

[stefan-mysten]

Thanks @amnn for the suggestions. I think this is ready now!