Int cannot represent non 32-bit signed integer value: 1234567893333333 returns a 400 status code, correct?

[magnusottosson]

I have a simpel schema like

type Query {
    hello(id:Int): String
  }

and try to request this using:

query ExampleQuery {
  hello(id:1234567893333333)
}

This will return an error since the client tries to fetch data using something that is not an Int. The response will be something like:

{
  "data": {},
  "errors": [
    {
      "message": "Int cannot represent non 32-bit signed integer value: 1234567893333333",
    }
  ]
}

The default Apollo server will return this error with status code 400? Is that correct? I would have expected a 200 since the query is kind of correct... or is it not?

[glasser]

This operation fails to validate against your schema, because what you've provided is not an Int. (It would be the same issue if you had put a string there, say.) As documented at https://www.apollographql.com/docs/apollo-server/data/errors#setting-http-status-code-and-headers Apollo Server's default behavior for parse and validation failures is a 400 error.

[magnusottosson]

If Apollo Server can't parse the request into a legal GraphQL document and validate it against your schema, it responds with a 400 status code. This can also happen with other request problems, such as if a client attempts to send a batched HTTP request when allowBatchedHttpRequests isn't enabled or if CSRF prevention blocks a request.

I wouldnt say that sending a number bigger than an Int makes the server unable to parse the request. If I would batch multiple request all the others would still work?

[glasser]

There's two things in that sentence: parsing and validation. Parsing means "have you written something that uses the GraphQL language correct" (independently of schema). You are correct that your document does not have parse errors.

Validation means "is what you have written appropriate for your server's schema". That query is not valid for your schema, just like how { fieldThatDoesNotExist }, { hello(argThatDoesNotExist: 1) }, and { hello(id: "a string") } are not valid.

If you don't like this behavior, you can change requestContext.response.http.status in a willSendResponse plugin hook (among other approaches).

[magnusottosson]

I understand the behaviour and might actually agree with your arguments... I just like how transportation independent GQL is and in this case we involve status codes for something that the schema and error message in the response would solve anyway...

In this case I understand how the framework argues and I will live with it :) I rather work with the framework the way it's supposed to work even if I don't fully agree with the way it works :) Just wanted to make sure I fully understand it.

Thank you for taking the time to answer my questions.

[glasser]

Yeah, to some degree this is the distinction between "request error" and "field error" in the main GraphQL spec.

And this is the direction that the new-ish "GraphQL over HTTP" spec is moving in (https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md); that spec mandates the 4xx errors for validation errors only when using the newfangled application/graphql-response+json response type but allows it (for compatibility reasons) for application/json responses too.