Different status code when using variables

[mantomas]

Hello everyone,
when using variables to create query, do you know if I can control the status code returned when invalid variable names are used (field not exist in the schema etc.)? When I pass invalid field through variables, the overall status code returned is 200 with response like this:

{
  "data": null,
  "errors": [
    {
      "message": "Variable '$input' got invalid value {'required_field': 'teststring', 'bad_field': 'badstring'}; Field 'bad_field' is not defined by type 'WriteObjInput'. Did you mean 'int_field', 'uri_field', 'base64_field', 'email_field', or 'enum_field'?",
      "locations": [
        {
          "line": 1,
          "column": 20
        }
      ],
      "trace_id": "0xabf99e960e96e5fae356a815409f3495"
    }
  ]
}

However when I pass the values directly, the overall status code is 400 (for the same input) with response:

{
  "errors": [
    {
      "message": "Field 'bad_field' is not defined by type 'WriteObjInput'. Did you mean 'int_field', 'uri_field', 'base64_field', 'email_field', or 'enum_field'?",
      "locations": [
        {
          "line": 3,
          "column": 43
        }
      ],
      "trace_id": "0x3824277025a29174f2550e80b555214d"
    }
  ]
}

The errors.message reasoning is partially identical and we would like to have the status code 400 in bot cases (mainly for testing purposes and also for not confusing users) - is it achievable? Or is the 200-400 difference in default behavior by design?

[rafalp]

Reason for different error code between one and other scenario is that invalid variable error comes from query executor, whereas undefined field error comes from query validator, which happens before query executor. It's not codified anywhere in spec, but its (at least it was when this was implemented) customary of HTTP servers to only return status code 400 when JSON payload didn't reach the query executor. Basically error 400 means that payload was not a valid GraphQL payload while 200 means that payload was valid, but not all fields were resolved successfully.

[mantomas]

Thanks @rafalp - if I'm reading it correctly, shouldn't it be 200 in both cases then? The query is syntactically valid in both cases. Or does it mean that for the 400 we are handling it wrong for that specific case?

[rafalp]

This is debatable. In first case the payload didn't reach the query executor, so there's no possibility for at least part of query to resolve successfully.

In other case the query entered query executor and only then an error was found with variables, inside the executor as it tried to deserialize variables contents using currently resolver field's args or inputs from schema. This next step occurs at the field's execution level, and it only means that individual field in query failed to execute (notice there's data value in other other case). It's entirely possible for other fields in query to still resolve correctly and their values be returned, producing the "partially successful" query result. This is why its recommended to look at errors and data keys in GraphQL response instead of trying to use status codes.