input validation too loose for string and boolean

[itajaja]

this

{ "foo": [1, 2, 3]}

is a correct payload for the muation

export default mutationWithClientMutationId({
  name: 'Test',

  inputFields: {
    foo: { type: new GraphQLNonNull(GraphQLString) },
  },
...

happening beacuse of this.

Clearly [1, 2, 3] is not a string and this should probably be rejected. This kind of coercion makes sense for output types, but for mutation input this seems very odd, even more so considering that other things are validated (non-nullness, integers). I mean, if [1, 2, 3] is a string, then why isn't "foo" a valid integer? I am seeing a disparity here. Is there a reason for that?

[leebyron]

This looks like a bug similar to #827

https://facebook.github.io/graphql/#sec-String

[vladar]

Coercion of booleans also seems invalid:

{"foo": "false"}

will be coerced to true by GraphQL Boolean Type without raising errors (here) even if specs explicitly says:

When expected as an input type, only boolean input values are accepted. 
All other input values must raise a query error indicating an incorrect type.

[leebyron]

Now fixed in master and will be included in the next release