`MetaService.Get` fails because the schema of the JSON in the API response is different from the expected in `APIMeta.Domains` type

[polamjag]

Downstream issue: integrations/terraform-provider-github#2357

GitHub has a meta information API, and go-github has a corresponding implementation:

• https://docs.github.com/en/rest/meta/meta?apiVersion=2022-11-28#get-github-meta-information
  • Can be called in https://api.github.com/meta
• https://pkg.go.dev/github.com/google/go-github/v63/github#MetaService
  • https://github.com/google/go-github/blob/882755a047ea3e09b2f5f4a0e888d9a12cf2852f/github/meta.go

In the response of this API endpoint, the JSON unmarshal always seems to fail for the Domains field -- because the type of the value is different from what is expected.

In go-github, values under domains property is expected to be map[string][]string:

go-github/github/meta.go

Lines 73 to 75 in 882755a

	// A map of GitHub services and their associated domains. Note that many
	// of these domains are represented as wildcards (e.g. "*.github.com").
	Domains map[string][]string `json:"domains,omitempty"`

But it actually looks like this (see https://api.github.com/meta):

{
  ... snip ...,
  "domains": {
    "website": [ "*.github.com", ... snip ... ],
    "codespaces": [ "*.github.com", ... snip ... ],
    "copilot": [ "*.github.com", ... snip ... ],
    "packages": [ "mavenregistryv2prod.blob.core.windows.net", ... snip ... ],
    "actions": [ "*.actions.githubusercontent.com", ... snip ... ],
    "artifact_attestations": {
      "trust_domain": "",
      "services": [ "*.actions.githubusercontent.com", ... snip ... ]
    }
  }
}

The values under artifact_attestations field clearly deviates from the []string type.

This incompatibility causes MetaService.Get() to fail with errors like Error: json: cannot unmarshal object into Go struct field APIMeta.domains of type []string.

[gmlewis]

Thank you, @polamjag !
It looks like we need:

Domains map[string]json.RawMessage `json:"domains,omitempty"`

instead.

Do you want to write a PR for this issue, or shall I open this up to other contributors to this repo?

[lrstanley]

I was actually just working on a PR to fix this. Was planning on changing it to a struct with fields for each domain type. @gmlewis, as far as json.RawMessage, is there a reason this would be preferred? Is there another component in this library that I could use as an example, for the PR? (e.g. using methods for fetching contents within the json.RawMessage?)

[gmlewis]

I was actually just working on a PR to fix this. Was planning on changing it to a struct with fields for each domain type. @gmlewis, as far as json.RawMessage, is there a reason this would be preferred? Is there another component in this library that I could use as an example, for the PR? (e.g. using methods for fetching contents within the json.RawMessage?)

According to the official documentation located here:
https://docs.github.com/en/rest/meta/meta?apiVersion=2022-11-28#get-github-meta-information
what we currently have should work correctly.

In the past, when we have experienced conflicts between what the official documentation says it returns and what it actually returns, we have typically preferred to first contact GitHub Tech Support to see if they have a recommendation, then if not, we try to make our endpoints be able to flexibly handle whatever the API throws at us.

So unless you know exactly what the API is going to be sending back (sometimes we have had GitHub engineers provide PRs in the past where they knew more than the documentation was stating... maybe you are one?) then if we make assumptions based on what we are receiving, then we set ourselves up for more breakages in the future.

HOWEVER, if you believe that you can map our all the return types correctly in a PR, I'm fine with doing that.

What's the worst that can happen?!? We just make a new major release, and it is pretty obvious by now that we have no troubles doing that. 😂

Therefore, @lrstanley - if you want to make a PR with struct fields for each domain type, let's go for it. 😄