-
-
Notifications
You must be signed in to change notification settings - Fork 722
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Annotation Based DefaultValues only works for strings #4220
Comments
That has nothing todo with strict 😅 we just implement already the spec draft. The new spec release is slated for later this month. It will take a while for tools to update certain things. Hot chocolate 12 also already implements features of the very next spec draft like defer and stream. |
I read the 2021 spec and you're right: default values don't care if the type is non nullable. That raises an interesting question. Why were default values in version 11.3.7 of hot chocolate not working with non null types? Having checked the 2018 spec, it seems that it was valid to set a default value for a non null field/argument. That makes me think that default values working in version 12 but not 11.3.7 isn't a result of implementing the newest spec. |
Because the 2018 spec had some issues with validation rules... I have to look them up again. But if you would implement the 2018 spec validation rules as described you would run into this... I need to check again my discussion notes with Ivan from GraphQL-js but there were contradicting rules. |
Interesting. Thanks for sating my curiosity. On an unrelated note, I think Hot Chocolate is a great tool. Keep up the good work. |
BTW there is a new draft on default values written by Benji that is not going into the 2021 spec draft. If you are interested in the odd cases. He is trying to root a lot of these cases out and streamline the handling of default values. It is at RFC 2 and is slated for next years spec release. |
Is there an existing issue for this?
Describe the bug
The DefaultValue attribute only works for strings. Take the following class:
It produces the following SDL:
Note that the Boolean, Int, Float, and MyEnum fields are all non-nullable despite having default values defined. When making a request to the endpoint, the non-null requirement makes it so those fields have to be set in the input, treating them exactly the same as non-null fields without a default argument specified in 11.3.7. It recognizes the defaults in 12.0.0-rc.6.
I also tried this with the following class:
Note that this time, the bool, int, double, and MyEnum are all nullable. Nevertheless, the exact same SDL gets produced.
Update: I originally tested this in 11.3.7. I updated my examples to account for a bug fix that wasn't included in that version.
Steps to reproduce
You can also attempt to hit the graphql endpoint with an editor of your choice. If you attempt to use the
returnTypePassedIn
query without specifying the bool, float, enum, and int fields,you'll get an error like "The field 'field name' is required and must be set."the query will work in 12.0.0-rc.6, but fail in 11.3.7.Relevant log output
No response
Additional Context?
No response
Product
Hot Chocolate
Version
12.0.0-rc.6
The text was updated successfully, but these errors were encountered: