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

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

Open
Shane32 opened this issue May 27, 2024 · 4 comments · May be fixed by #1098
Open

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

Shane32 opened this issue May 27, 2024 · 4 comments · May be fixed by #1098

Comments

@Shane32
Copy link

Shane32 commented May 27, 2024

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.

@Shane32 Shane32 linked a pull request May 27, 2024 that will close this issue
@benjie
Copy link
Member

benjie commented Jun 4, 2024

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!

@benjie benjie added 💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md) and removed 💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md) labels Jun 4, 2024
@benjie
Copy link
Member

benjie commented Jun 4, 2024

Moving the RFC label to the PR.

@Shane32
Copy link
Author

Shane32 commented Jun 4, 2024

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.

@Shane32
Copy link
Author

Shane32 commented Jun 4, 2024

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

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 a pull request may close this issue.

2 participants