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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix __typename inside router response #6009
Fix __typename inside router response #6009
Changes from 2 commits
7402a1b
d7b4f90
6de302e
4241a8c
cad5265
c052392
0d61767
9115847
ea7ded9
b411e5f
ddeed8d
e871c93
f637705
95cfb79
f15535e
b9d3f77
37c5b1e
39a9fdc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here, we tried to use __typename values returned by the subgraph but didn't validate them. I assume (not tested) it can even be the name of the interface if the subgraph uses
@interfaceObject
According to the GraphQL spec,
__typename
should always use an object name (interfaces and unions are forbidden), so I changed the code to first usecurrent_type
(which is always valid) and then fallback to using the subgraph's value only ifcurrent_type
is not an object type.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be checked with what the output rewriting code in the QP is doing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what to do here.
Realistically, I can't inspect QP in the scope of this PR.
I can revert this particular change, because it separated from other fixes.
@Geal Do you think it worth to revert it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change looks correct to me: when a field is an object type in the supergraph we know what the correct
__typename
is and could even skip asking the subgraphThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are still inside root selection, even if we go inside an inline fragment.
So it should be
apply_root_selection_set
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this sounds reasonable but looks like a dangerous change. Do you have a test that would show what happens before and after that change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes it tested here:
router/apollo-router/tests/integration/subgraph_response.rs
Lines 34 to 82 in e871c93
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why should
{ __typename topProducts { name } }
return a nulldata
if the subgraph returns null?topProducts
is a nullable field, right?Is it for the case where the subgraph would nullify because there was a non nullable field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, it was mainly to test null propagation that goes up to
data.
However, graphql servers can return
data: null
if execution is started by no resolvers executed:https://spec.graphql.org/October2021/#sel-FAPHPHCAACEBr6C
For example, here is the test from graphql-js:
https://github.com/graphql/graphql-js/blob/993d7ce2ee6db2a13973b037817f3eac60607b8a/src/execution/__tests__/executor-test.ts#L971-L981
These cases are but could happen, so we should keep semantics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the "right" way would be to detect from errors if we got a null because a non null field was nullified by the subgraph, but that may be too complex
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we switch default value to
execute_recursively
to be an object as discussed earlier that would mean we would get empty object in most of the cases.But we should inspect QP execution to see all possible scenarios.