-
Notifications
You must be signed in to change notification settings - Fork 242
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
Ensure error resolving an entity don't impact resolvable ones (for main
branch)
#1306
Conversation
Maybe it's because it's a little late in the day for me, but I think I would probably greatly benefit from a walk through of this code. Would you maybe have time tomorrow? Either way I'll dig in deeper tomorrow. |
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.
Couple of super minor comments
@@ -489,7 +489,17 @@ function executeSelectionSet( | |||
const selections = (selection as QueryPlanFieldNode).selections; | |||
|
|||
if (typeof source[responseName] === 'undefined') { |
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.
should we simplify to
if (source[responseName] === undefined)
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.
Oops, did you not touch this line? Never mind.
query-graphs-js/src/querygraph.ts
Outdated
@@ -353,6 +360,16 @@ export class QueryGraph { | |||
const indexes = this.typesToVertices.get(typeName); | |||
return indexes == undefined ? [] : indexes.map(i => this.vertices[i]); | |||
} | |||
|
|||
externalTester(source: string) { |
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.
nit: return type
query-planner-js/src/buildPlan.ts
Outdated
@@ -1637,7 +1642,9 @@ function inputsForRequire(graph: QueryGraph, entityType: ObjectType, edge: Edge, | |||
fullSelectionSet.add(new FieldSelection(new Field(entityType.typenameField()!))); | |||
fullSelectionSet.mergeIn(edge.conditions!); | |||
if (includeKeyInputs) { | |||
fullSelectionSet.mergeIn(additionalKeyEdgeForRequireEdge(graph, edge).conditions!); | |||
const keyCondition = getLocallySatisfiableKey(graph, edge.head); | |||
assert(keyCondition, () => `No key found for require on ${edge}`); |
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.
Some times, when a @requires is just after a key, we can simply collect the required field before taking the key. Other times, we encounter a @require in a type T of a subgraph A, and have to jump to subgraph B to get the required field. In that case, once we've collected the required fields, we need to "resume" query on T in A, and that means using a key there. The code dealing with that post-require "return key" later case was incorrect, essentially using a key on subgraph B instead of one on subgraph A. As a consequence, subgraphs that shouldn't have been allowed to compose (because they were missing the needed key on A) were allowed to composed, and the code later failed during query planning. This commit fixes this issue, and adds tests for that case. One of the test introduced _fails_ as of this commit, but that is due to the problem describe on apollographql#376 and the fix will be in a followup commit.
Fixes apollographql#376 Co-authored-by: Sylvain Lebresne <sylvain@apollographql.com>
This PR has the same fix than in #1305, but for
main
.However, testing this also uncovered another issue with
@requires
onmain
(fed 2 code), and this PR also has this additional fix. So first commit is that "other" fix (but it includes all the tests), and second commit is the fix of #1305.