-
Notifications
You must be signed in to change notification settings - Fork 254
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 errors reading fed1 supergraphs #1351
Conversation
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.
code looks good! would like a few more tests:
- a negative test (ensure that types with remaining fields are not removed) mainly for documentation (i suspect many things would break if that functionality were broken)
- testing the recursive removal of empty unions, fields, and the other cases we handle
@@ -0,0 +1,110 @@ | |||
import { buildSupergraphSchema, extractSubgraphsFromSupergraph } from ".."; | |||
|
|||
test('handles types having no fields in a subgraph correctly', () => { |
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.
could we add another test which exercises the path where we remove fields in a subgraph but do not remove the whole type? mainly for documentation of the behavior—i expect this is exercised in other tests.
ref.removeRecursive(); | ||
break; | ||
case 'UnionType': | ||
if (ref.membersCount() === 0) { |
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.
do we have tests that exercise this?
A fed1 supergraphs doesn't always have enough information to know in which subgraph a type is defined, so when extracting a subgraph from the supergraph, we sometime "optimistically" add a type to that subgraph, but later have to remove it if it turns out the type has no fields in that subgraph. The issue was that this type was sometimes referenced and removing it left the references invalid. Instead, this patch ensures those references are also removed (we can infer those were also added mistakenly due to a lack of information). Additionally, the commit slightly improves the handling of errors happing while extracting subgraphs from the supergraph, providing clearer messages and, for debugging, allows to dump the extracted subgraph (but only when an `APOLLO_FEDERATION_DEBUG_SUBGRAPHS` env variable is set to avoid surprises).
9ce7188
to
1bc13f7
Compare
Thanks for the review. Pushed a few more tests indeed. |
A fed1 supergraphs doesn't always have enough information to know in
which subgraph a type is defined, so when extracting a subgraph from
the supergraph, we sometime "optimistically" add a type to that
subgraph, but later have to remove it if it turns out the type has
no fields in that subgraph. The issue was that this type was sometimes
referenced and removing it left the references invalid. Instead, this
patch ensures those references are also removed (we can infer those
were also added mistakenly due to a lack of information).
Additionally, the commit slightly improves the handling of errors
happing while extracting subgraphs from the supergraph, providing
clearer messages and, for debugging, allows to dump the extracted
subgraph (but only when an
APOLLO_FEDERATION_DEBUG_SUBGRAPHS
envvariable is set to avoid surprises).