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

Validate that the operation's root type is valid #225

Merged
merged 1 commit into from
Jun 6, 2022

Conversation

benjaminjkraft
Copy link
Contributor

Turns out neither we (nor anyone else) were validating this, because the
spec didn't say explicitly to validate it. So you could do
mutation { bogus } even if the schema has no mutation types, or worse,
any syntactically valid query if the schema is totally empty.

In graphql/graphql-spec#955 I'm adding it to the spec, and in
graphql/graphql-js#3592 someone else is adding it to graphql-js. So we
should too, once those land! At that point we should also likely
reimport the relevant tests, instead of the ones I wrote here, but I
figured I'd put the PR up now so folks can review the non-test parts if
you like.

Fixes #221.

Turns out neither we (nor anyone else) were validating this, because the
spec didn't say explicitly to validate it.  So you could do
`mutation { bogus }` even if the schema has no mutation types, or worse,
any syntactically valid query if the schema is totally empty.

In graphql/graphql-spec#955 I'm adding it to the spec, and in
graphql/graphql-js#3592 someone else is adding it to graphql-js.  So we
should too, once those land!  At that point we should also likely
reimport the relevant tests, instead of the ones I wrote here, but I
figured I'd put the PR up now so folks can review the non-test parts if
you like.

Fixes vektah#221.
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.05%) to 92.234% when pulling 8cbfcec on benjaminjkraft:known-root-type into 6519773 on vektah:master.

// update this switch block to add the new operation type.
panic(fmt.Sprintf(`got unknown operation type "%s"`, operation.Operation))
}
if def == nil {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Am I wrong to think that def cannot be nil here due to an unsupported operation type, given that it would have panicked above in the default switch?
I'm not sure under what circumstances that walker.Schema.{Subscription|Mutation|Query} would be nil, but I haven't played with this area in a while.

Copy link
Contributor Author

@benjaminjkraft benjaminjkraft Jun 6, 2022

Choose a reason for hiding this comment

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

This gets hit in the case we are interested in -- you wrote mutation { ... } but the schema has no type Mutation (and, if we are being precise, no schema { mutation: SomeOtherType }). The panic is only if you wrote bogus { ... }, i.e. a totally invalid operation type, and that we should have rejected in parsing (which is why it's a panic).

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, right. the error message case is when it is invalid in the case of this particular schema.

@StevenACoffman
Copy link
Collaborator

Overall I very much like this, and I'm very much looking forward to having the imported tests updated. Any improvements that have been made upstream would be welcome, since they were a little... weak before.

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.

gqlparser accepts a schema with no query type and validates any query against it
3 participants