You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Input object fields may be required. Much like a field may have required arguments, an input object may have required fields. An input field is required if it has a non-null type and does not have a default value. Otherwise, the input object field is optional.
In this case, the field has a default value, so it should be treated as optional.
Note that if I make the base input field nullable, the default value is respected and the problem goes away. However, that allows a client to explicitly pass base: null which breaks the resolver implementation (it relies on base always having an integer value, using the default of 10 as needed). So I would like to keep the input field non-nullable.
On a side note: I expect the same behavior whether field arguments are provided inline in the query or provided via operation variables, and was quite surprised to learn of the difference here. My test suite tends to just use inline arguments for simplicity, which allowed this issue to get through to production.
Are there any cases where I should expect operation variables and inline arguments to behave differently?
The text was updated successfully, but these errors were encountered:
Describe the bug
Non-nullable input field default values work correctly when using inline argument values, but appear to be ignored when using operation variables.
Versions
graphql
version:2.3.18
.rails
(or other framework): N/AGraphQL schema
GraphQL query
This query works as expected:
But if I use a variable for
operands
, it unexpectedly fails:Steps to reproduce
Put this into a script and run it:
Expected behavior
I expect output like:
Actual behavior
I instead get output like:
Additional context
The GraphQL spec covers this situation:
In this case, the field has a default value, so it should be treated as optional.
Note that if I make the
base
input field nullable, the default value is respected and the problem goes away. However, that allows a client to explicitly passbase: null
which breaks the resolver implementation (it relies onbase
always having an integer value, using the default of10
as needed). So I would like to keep the input field non-nullable.On a side note: I expect the same behavior whether field arguments are provided inline in the query or provided via operation variables, and was quite surprised to learn of the difference here. My test suite tends to just use inline arguments for simplicity, which allowed this issue to get through to production.
Are there any cases where I should expect operation variables and inline arguments to behave differently?
The text was updated successfully, but these errors were encountered: