Add key fields to selections even when they're already selected with an alias

[BoD]

No description provided.

[svc-apollo-docs]

⚠️ Docs preview not attached to branch

The preview was not built because the PR's base branch main is not in the list of sources.

An Apollo team member can comment one of the following commands to dictate which branch to attach the preview to:

• !docs set-base-branch release-2.x
• !docs set-base-branch release-3.x
• !docs set-base-branch release-4.x

Build ID: 20c26efb3a364a0cd31e0bfe

[martinbonnin]

Could we avoid duplicating the field? I think we have everything for that in CacheKeyGeneratorContext.field.selections?

Fragments make it a bit more complicated (because we don't have the full schema at runtime so a given field may be key in one fragment but not in the other and we probaby wouldn't know which one...).

[martinbonnin]

Suggested change

	val fieldNames = parentFields + selectionSet.filterIsInstance<GQLField>().map { it.alias ?: it.name }.toSet()
	val fieldNames = parentFields + selectionSet.filterIsInstance<GQLField>().map { it.responseName() }.toSet()

[martinbonnin]

Another option is to codegen the key responseNames in CompiledField... We could make it so that we only codegen them if there are aliases but it's still one extra pointer for every field.

Note: just realized that the keyfields are added after validation so we're potentially sending invalid queries to the server 😬

[BoD]

Could we avoid duplicating the field? I think we have everything for that in CacheKeyGeneratorContext.field.selections?

Ah yes we could look for the field's name, and fallback to its alias(es).

But I actually don't follow your caveat about fragments, do you have an example?

[martinbonnin]

union Stuff = Book | Banana

interface Product {
  # ...
}
type Book @typePolicy(keyFields: "isbn") implements Product {
  isbn: String!
  # ...
}

query GetStuff {
  stuff {
    ... on Product {
      ... on Book {
        identifier: isbn
      }
    }
  }
}

Walking compiledField.selections bumps into Product. In order to know if we need to collect the fragment, we need to know whether Book is an instance of Product. Might be doable but it's not trivial logic.

Ultimately, it probably requires that we implement collectFields() inside the CacheKeyResolver just like we're doing in the Normalizer