-
Notifications
You must be signed in to change notification settings - Fork 271
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
bubble up errors to the next nullable field (#528)
* aggregate subgraph errors, update their paths to match the merged response and remove the message to hide private infra information * use the schema and the query to validate the response data, inserting a null where there is an invalid value, and for non null types, replacing the parent object or list with a null, bubbling up in the response until the next nullable type * handle the response validation inside response formatting this makes more sense to validate while we are already exploring the response tree. It is also necessary to have the selection sets availalble when validating, otherwise we get errors on nonNull fields even if they are not present This introduces a limited kind of query validation, since we need to check that some elements of the query match the schema. That validation returns a None on failure instead of a meaningful error message. We should wait for apollo-rs semantic analysis to provide good error messages instead (and delete all of that code) * error propagation has a side effect: now all response formatting tests will need a valid schema * clean up the situation around query operation names, where passing a query with an invalid name or no name could result in the response object being returned without filtering * support fragments at the top level this requires a special case when applying selections, since the top level object will not provide a __typename field * deduplicate selections if a field is requested multiple times, it should only be obtained once * if we already know the type of a selection, we might not get __typename in some cases, an object might not contain a typename. Example: schema: type Query { get: Thing } type Thing { name: String } query { get { ... on Thing { name } } } Here the operation will directly be handled by the subgraph, and it might not return a __typename field, since we already know which type will be returned (while for a union or interface we will get a __typename). Now when parsing the query we need to store the "current type", which is known because the Selection::from_ast function is called from the parent selection creation. If that type and the fragment's type condition match, we won't need to check it. There's an additional subtlety here: fragments used as fragment spread might be defined in the query, not the schema, and might be later in the query. Since we're lazily going through the query's AST, it makes sense here to store the current type, then when applying the fragment spread, look up the actual fragment and check the expected type there * the type condition is optional on inline fragment The following query is valid: query { topProducts { ... { inStock } } this commit also fixes fragment spread to use FieldType::inner_type_name on fragment spreads, otherwise lists and non null fields would not apply
- Loading branch information
Showing
8 changed files
with
2,329 additions
and
266 deletions.
There are no files selected for viewing
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
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
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
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
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
Oops, something went wrong.