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

Validation/coercion of input variables violates the GraphQL spec #223

Open
dkbarn opened this issue Aug 13, 2024 · 1 comment
Open

Validation/coercion of input variables violates the GraphQL spec #223

dkbarn opened this issue Aug 13, 2024 · 1 comment

Comments

@dkbarn
Copy link

dkbarn commented Aug 13, 2024

When callling graphql-core's execute() function with variable_values which do not pass validation -- for example, including an unexpected key in the variable_values dictionary -- the current behavior is that an ExecutionResult object is returned from the function, with the associated GraphQLError present inside it. Instead, this should be treated as a Request error, according to the spec, meaning that a GraphQLError should be raised from execute().

The GraphQL spec states:

Request errors
Request errors are raised before execution begins. This may occur due to a parse grammar or validation error in the requested document, an inability to determine which operation to execute, or invalid input values for variables.

This means that it is incorrect for the coerce_variable_values function to be returning a GraphQLError inside an ExecutionResult:

on_error(
GraphQLError(
f"Variable '${var_name}' expected value of type '{var_type_str}'"
" which cannot be used as an input type.",
var_def_node.type,
)
)

doing so means that a response payload is returned containing both an "errors" key and a null "data" key. Again, this a violation of the spec:

If a request error is raised, execution does not begin and the data entry in the response must not be present. The errors entry must include the error.

@Cito
Copy link
Member

Cito commented Aug 14, 2024

Hi @dkbarn, thanks for bringing this up.

Actually I believe this is ok in view of the comment directly in front of the lines you linked to. The error in the variable values should be caught during validation already and never happen when execute() is called via the high-level graphql() function that includes validation. Conversion of the ExecutionResult to a JSON response payload and removal of the data property with a null value for a request error should happen at the server level.

If you still believe the behavior of the values module should be changed, please report upstream at the GraphQL.js project since the goal of GraphQL-core is to implement the exact same behavior as this reference implementation. See the corresponding code here.

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

No branches or pull requests

2 participants