Validate input types

[frekw]

I'm opening this at this point as a reference for further discussion.

Yesterday I ran across a case where we incorrectly validate the following query:

type Query {
  dummy(input: Int): Int
}

query SomeQuery($var: Int!) {
  dummy(input: $var)
}

which will incorrectly execute for the following input {"var": null} (which resulted in some frontend tooling on our breaking down in weird ways).

What happens is that Caliban properly validates that the variable can be assigned to the argument (works since Int! is more specific than Int), and that the provided value of the variable (null can be assigned to Int). However, the query isn't valid in the first place since null shouldn't have been assignable to Int! in the first place.

However, a lot of the validation errors end up becoming really wonky, especially in the case of mismatched input types since we'll only add used types to the "known" types and not e.g all scalars, which means that we end up with a lot of errors of the likes of Int is not an input type rather than (Variable 'x' usage is not allowed because its type doesn't match the schema (Int instead of String)., which I think is undesirable. I think a work-around for this would be to expand the types of the schema to always include the primitive types String, Float, Int and Boolean. What do you think?

[frekw]

How should we format coercion errors? With some errors context similar to Validator.scala?

[ghostdogpr]

If the path was available that would be the bext UX

[frekw]

✅

[ghostdogpr]

Is it possible to include only those that are actually used in other parts of the schema?

[ghostdogpr]

Ah, I see the problem you mentioned though. Maybe instead of adding these to the schema, just add them during the validation?

[frekw]

Good idea, I changed that in 102a38a!

[frekw]

Ok @ghostdogpr I've cleaned this up now, hopefully it should be good to go 🙏

[ghostdogpr]

LGTM, just some minor comments

[frekw]

I've fixed the imports now @ghostdogpr 👍