Conversation
…utation query to schema mismatch""
…idate-catch_operation_to_schema_mismatch
|
To chat about later - this problem would always be caught at the execution step, and I think execution is a more natural place to check this sort of problem |
|
To do: check the reference implementation graphql-js |
|
Interesting, this is a gap in the specification, which our .NET implementation friends have also found. This is a proposal to formalise that mutation and subscription operations exist in the schema before execution. Issue link: graphql/graphql-spec#1097 |
|
Coming back to this PR, a new spec change is landing soon which adds validation for this failing test case, where an operation doesn't exist in the schema. This PR has all the changes: graphql/graphql-spec#955 |
|
3 days ago this RFC was promoted to the RFC 2 Draft stage graphql/graphql-spec#955 |
…idate-catch_operation_to_schema_mismatch
Test Results 306 files ±0 306 suites ±0 46s ⏱️ -1s Results for commit c467a02. ± Comparison against base commit d370d0b. This pull request removes 151 and adds 132 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
| then: | ||
| result.errors.size() == 1 | ||
| result.errors[0].class == MissingRootTypeException | ||
| ((ValidationError) result.errors[0]).validationErrorType == ValidationErrorType.UnknownOperation |
There was a problem hiding this comment.
I'd like to discuss this
Previously, the same sort of problem would be caught at execution time, throwing a MissingRootTypeException if the operation could not be executed. Given that I've now moved forward validation, it's very unlikely the old exception will ever be triggered. However for safety I'd like to be defensive and leave in the old code. See SchemaUtil and getOperationRootType.
There was a problem hiding this comment.
Discussed offline - will keep in the old error in case, to be conservative
| type Subscription { | ||
| field: String | ||
| } | ||
|
|
There was a problem hiding this comment.
This test needed an adjustment to be valid
|
|
||
| private String formatOperation(OperationDefinition.Operation operation) { | ||
| return StringKit.capitalize(operation.name().toLowerCase()); | ||
| } |
There was a problem hiding this comment.
Our Operation enums are ALL CAPS and I thought that was too shouty
| addError(UnknownOperation, operationDefinition.getSourceLocation(), message); | ||
| } else if (documentOperation == OperationDefinition.Operation.QUERY | ||
| && graphQLSchema.getQueryType() == null) { | ||
| // This is unlikely to happen, as a validated GraphQLSchema must have a Query type by definition |
There was a problem hiding this comment.
A valid GraphQLSchema should have already been checked for a query type, I am being defensive here
…idate-catch_operation_to_schema_mismatch
Update: Dec 2024
This PR brings forward validation to check an operation exists in the schema.
Previously, this was checked at execution time. Now it will be checked at documentation validation time.
The motivation for this change was a change in the specification, which is currently in RFC2 and is about to be merged in. See graphql/graphql-spec#955
We also had folks from the community request this. Originally from #2741 and #2740.
I've aligned names with the reference implementation graphql/graphql-js@50d555c