Fix issue where the query planner was incorrectly not querying `__typ… #2366
Conversation
…ename` in a subgraph fetch when `@interfaceObject` is involved When we fetch data for abstract types (typically interface), we usually need to make sure that `__typename` is queried as the code that post-process responses may have to know the concrete type of an object in the response (to know if it should be included or not). There is a method that `__typename` for abstract types in fetch selections, but that method was not doing it for fragments for some reason (a oversight really). While this never created an issue before, this is now problematique in some case with `@interfaceObject` and so this commit ensure `__typename` is always added, even for fragments. Working on this issue, I also noticed that the part of the code that in the query planner that eliminates useless fetches (sometimes, due to how the query planner process work, some fetches are created but end up not querying anything useful (meaning that they only query things already queried)) had not been updated for `@interfaceObject` and was not doing its job in some case. This lead to query plans including unecessary fetches (which can have a non-negligible impact). This commit also fix that issue.
👷 Deploy request for apollo-federation-docs pending review.Visit the deploys page to approve it
|
🦋 Changeset detectedLatest commit: 18b1b40 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 |
|
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. |
| @@ -881,6 +881,7 @@ describe('buildQueryPlan', () => { | |||
| __typename | |||
| ... on Image { | |||
| ... on NamedObject @include(if: $b) { | |||
| __typename | |||
There was a problem hiding this comment.
Note to reviewers: there is a handful of cases, like this one, where the change of this commit adds a __typename that wasn't there before, even though it's technically redundant (we already ask for the __typename of this object a few lines above). Imo, that's fine and it's not worth being bothered by: it doesn't happen much and asking for __typename is always pretty cheap, so this probably have no measurable effect. We can try to avoid this kind of duplication later if that bother someone and we have spare cycles, but the check implementation may create more inefficiencies in query planner than it saves at execution.
…ename
in a subgraph fetch when@interfaceObject` is involvedWhen we fetch data for abstract types (typically interface), we usually need to make sure that
__typenameis queried as the code that post-process responses may have to know the concrete type of an object in the response (to know if it should be included or not).There is a method that
__typenamefor abstract types in fetch selections, but that method was not doing it for fragments for some reason (a oversight really). While this never created an issue before, this is now problematique in some case with@interfaceObjectand so this commit ensure__typenameis always added, even for fragments.Working on this issue, I also noticed that the part of the code that in the query planner that eliminates useless fetches (sometimes, due to how the query planner process work, some fetches are created but end up not querying anything useful (meaning that they only query things already queried)) had not been updated for
@interfaceObjectand was not doing its job in some case. This lead to query plans including unecessary fetches (which can have a non-negligible impact). This commit also fix that issue.