Don't treat entity interface __typename refinements as useless
#2775
Conversation
🦋 Changeset detectedLatest commit: 4fd48ba The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Deploy Preview for apollo-federation-docs canceled.
|
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
| if (parentType && isInterfaceType(parentType)) { | ||
| // Lastly, we just need to check that we're coming from a subgraph | ||
| // that has the type as an interface object in its schema. | ||
| return this.parents().some((p) => { |
There was a problem hiding this comment.
Just for my own edification, probably just being dense, but why are there multiple parents here?
There was a problem hiding this comment.
My understanding (and would appreciate @pcmanus to confirm) is that we'd rarely have more than one parent in practice, but it's possible in the case that we also happen to be in a diamond-shaped dependency situation.
Fix specific case for requesting
__typenameon interface entity typeIn certain cases, when resolving a
__typenameon an interface entity (due to it actual being requested in the operation), that fetch group could previously be trimmed / treated as useless. At a glance, it appears to be a redundant step, i.e.:It's actually necessary to preserve this in the case that we're coming from an interface object to an (entity) interface so that we can resolve the concrete
__typenamecorrectly.Ref: #2743
(this fixes one of the queries from the issue but not both)