fix: __typename when formatting response in some @interfaceObject cases
#2530
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pcmanus
force-pushed
the
response-format-itfObj-issue
branch
from
2a2c417 to
5872d0e
Compare
Geal
suggested changes
Feb 3, 2023
apollo-router/src/spec/query.rs
Outdated
| @@ -150,6 +150,7 @@ impl Query { | |||
| variables: Object, | |||
| schema: &Schema, | |||
| ) -> Vec<Path> { | |||
| println!("Formatting: {response:?}"); | |||
There was a problem hiding this comment.
Suggested change
| println!("Formatting: {response:?}"); |
There was a problem hiding this comment.
Sorry about that. I've removed it and rebased (and updated to the new changelog thingy).
…oducted by `@interfaceObject` The introduction of `@interfaceObject` in federation 2.3 has for consequence that a subgraph (that uses an `@interfaceObject`) may return in its response a `__typename` that corresponds to an interface type in the supergraph (but which, locally to that subgraph, is an object type). The idea is that if that `__typename` is requested, then the query planner will ensure that another follow-up fetch will override that value so it maps to a proper object type. However, in some cases, that `__typename` is not queried, nor is there another reason to resolve the actual underlying implementation type of the underlying object (meaning that only fields of the interface are queried), and in that case the `__typename` may still point to the interface type when `format_response` is called. Unfortunately, that method currently nullify the whole object in such case, which is not the behaviour we want and was not caught in apollographql#2489.
pcmanus
force-pushed
the
response-format-itfObj-issue
branch
from
5872d0e to
4d6b600
Compare
Geal
approved these changes
Feb 6, 2023
abernix
changed the title
__typename when formatting response in some @interfaceObject cases
This was referenced Feb 8, 2023
Merged
abernix
pushed a commit
that referenced
this pull request
Feb 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The introduction of
@interfaceObjectin federation 2.3 has for consequence that a subgraph (that uses an@interfaceObject) may return in its response a__typenamethat corresponds to an interface type in the supergraph (but which, locally to that subgraph, is an object type).The idea is that if that
__typenameis requested, then the query planner will ensure that another follow-up fetch will override that value so it maps to a proper object type.However, in some cases, that
__typenameis not queried, nor is there another reason to resolve the actual underlying implementation type of the underlying object (meaning that only fields of the interface are queried), and in that case the__typenamemay still point to the interface type whenformat_responseis called. Unfortunately, that method currently nullify the whole object in such case, which is not the behaviour we want and was not caught in #2489.Complete the checklist (and note appropriate exceptions) before a final PR is raised.
Notes
[^1]. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this.
[^2]. Configuration is an important part of many changes. Where applicable please try to document configuration examples.
[^3]. Tick whichever testing boxes are applicable. If you are adding Manual Tests:
- please document the manual testing (extensively) in the Exceptions.
- please raise a separate issue to automate the test and label it (or ask for it to be labeled) as
manual test