Skip to content
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

Merged
merged 2 commits into from Jan 3, 2022

Conversation

pcmanus
Copy link
Contributor

@pcmanus pcmanus commented Dec 14, 2021

This PR has the same fix than in #1305, but for main.

However, testing this also uncovered another issue with @requires on main (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.

@pcmanus
Copy link
Contributor Author

pcmanus commented Dec 14, 2021

@clenfest: the second commit here is going to be review as part of #1305/#376 and feel free to skip it (though certainly happy with more eyes on it), but the 1st commit here is specific to the fed2, and I think you might be the most qualified to review. Do you mind?

@clenfest
Copy link
Contributor

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.

Copy link
Contributor

@clenfest clenfest left a 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') {
Copy link
Contributor

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)

Copy link
Contributor

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.

@@ -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) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: return type

@@ -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}`);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a slightly better error message? Suggestion: "Use of @require mandates a @key and no key was found on ${edge}"

Sylvain Lebresne and others added 2 commits January 3, 2022 13:44
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>
@pcmanus pcmanus merged commit 950eb93 into apollographql:main Jan 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Federation: Undefined behaviour and INTERNAL_SERVER_ERROR when returning external types that do not exist
3 participants