Mutation validates when schema does not support mutations

graphql-js currently considers the following bogus operation valid against the given schema:

# schema:
type Query { f: String }

# operation:
mutation { bogus }

In particular, if the schema does not define a root type for one of the GraphQL operation types (here mutation), graphql-js does not against such operations. In fact, this can even happen with queries:

# schema:
type T { f: String }

# operation:
query { bogus }

(edit: validate does complain here, although buildSchema does not.)

Of course, any server that tries to resolve such a query will crash, or at best return null. The spec does say that schemas must have a query root operation type (so the second schema is invalid) and that schemas with no mutation root operation type do not support mutations (so the first operation is invalid).

In practice, this has come up for me primarily in testing graphql libraries – while most real-world schemas support both queries and mutations, and users will typically look before assuming a server supports subscriptions, it’s easy in writing test schemas to forget that. But I’m sure there do exist servers which don’t have any mutations, too; I think my previous job had some such internal services, although since they were behind an Apollo federated gateway users would never see this.

I may have some time to write a PR for this. One question is whether it’s actually safe to start validating against schemas with no query root operation type; it wouldn’t surprise me if there are plenty of cases where users validate an extension schema (which may legitimately have no query root operation type) on its own, and currently it will validate. So it may be better to avoid the potentially-breaking change and validate both cases at the query stage. But I’d love to hear from maintainers as to their thoughts on that point. (edit: irrelevant if we keep the validation in validate rather than buildSchema.)

BTW, my suspicion is many other GraphQL libraries have this issue; I originally discovered it in vektah/gqlparser#221.

[yaacovCR]

Got it, thanks for clarifying. This is probable because of that check above, but perhaps simply removing it is not the answer. The strict view of FieldsOnCorrectType rule assumes the existence of the parent type because it’s only checking fields. We could automatically fail if the parent type does not exist or we could stay strict and introduce a new rule KnownOperationType

[benjaminjkraft]

That looks great, thanks for making the PRs! I should be able to attend, I’ll add to the agenda.