Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Handling of variable type errors does not conform to spec and appears inconsistent with graphql-js

See original GitHub issue

Currently, if a given variable does not conform to its declared type, a RuntimeException will be thrown when executing a query.

This does not conform to the spec, nor to any other graphql implementations I’ve been able to test against, including graphql-js.

Going through the relevant sections of the spec:

Section 6.1.2 specifies what happens when variable types mismatch: http://facebook.github.io/graphql/October2016/#sec-Coercing-Variable-Values

If a query error is encountered during input coercion of variable values, then the operation fails without execution. … … f. Otherwise, if value cannot be coerced according to the input coercion rules of variableType, throw a query error.

Section 7 describes how the response should look: http://facebook.github.io/graphql/October2016/#sec-Response

When a GraphQL server receives a request, it must return a well‐formed response. The server’s response describes the result of executing the requested operation if successful, and describes any errors encountered during the request.

There is no exception here for operations that fail without execution, and in fact section 7.2.1 explicitly describes how the response should look in this case: http://facebook.github.io/graphql/October2016/#sec-Response-Format

If the operation included execution, the response map must contain a first entry with key data. The value of this entry is described in the “Data” section. If the operation failed before execution, due to a syntax error, missing information, or validation error, this entry must not be present.

I guess this might be the biggest point of contention, as query error is not explicitly listed as one of the types of errors occurring before execution. However, as the spec does not give unambiguous descriptions of the different types of errors and their meanings, I think the most reasonable reading is that this specific type of query error is a validation error.

In any case, I think it would be helpful if the spec was made clearer on the error types.