graphql / graphql-spec

GraphQL is a query language and execution engine tied to any backend service.

Home Page:https://spec.graphql.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

No validation rule exists to assert mutation/subscription operations exist in the schema

Shane32 opened this issue · comments

When validating a document against a schema, there exists various validation rules for operations, but none to verify that if a mutation or subscription operation type is requested, that the schema is configured for such an operation.

For example, the below document would current pass all defined validation checks even with no mutation operation defined in the schema:

mutation {
  __typename
}

While per 6.2.2 the execution phase would fail the assertion that "mutationType is an Object type" and would fail to execute, this problem should be caught during validation, not execution.

Note that in the above sample, only 5.3.1 Field Selections could possibly fail validation. For GraphQL.NET, each validation rule assumes that prior validation steps have passed. For example, we do not raise errors about invalid fields when the parent field does not exist. So no error is raised due to 5.3.1. Further, __typename is a meta-field and would be not be compared to the schema in any case. We perform the assertion at the execution step pursuant to the GraphQL spec.

I suggest adding validation rule 5.2.4 indicating that for mutation or subscription operation types, the schema must be configured for the requested operation.

I agree with the need for this. Would you like to work on it? (You might consider applying for a small GraphQL Grant if you need some financial support.) I would expect there to be a round or two of edits via working groups and then this to be merged; it seems a pretty straightforward and non-controversial proposal/need!

Moving the RFC label to the PR.

I agree with the need for this. Would you like to work on it? (You might consider applying for a small GraphQL Grant if you need some financial support.) I would expect there to be a round or two of edits via working groups and then this to be merged; it seems a pretty straightforward and non-controversial proposal/need!

I just don't have the time, sorry. I'm working on @oneOf and federation within GraphQL.NET just now in my very-limited spare time. I hope the PR that I've submitted will be a good starting place if someone else wants to run with it and/or collect the grant.

Anyone may feel free to duplicate my PR into a new PR if so desired.