-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Validate default values #3448
Validate default values #3448
Conversation
@rmosolgo cc @benjie @RobertWSaunders this kinda/sorta does the right thing up front, but it's surfaced a bunch of other complications:
# Given
class DairyAnimal < GraphQL::Schema::Enum
value("COW", "Animal with black and white spots", value: 1)
end
# This used to be valid and isn't anymore
argument :animal, DairyAnimal, required: false, default_value: 1
# Instead you need this, which used to be invalid
argument :animal, DairyAnimal, required: false, default_value: "COW" Surprisingly (to me) it seems to get cast either way and the resolver still gets
And it would be a breaking change for everybody to update their enums.
# This doesn't work right now because it tries to validate the wrapped `[1]` with the unwrapped `Integer`.
argument :animal, [GraphQL::Type::Integer], required: false, default_value: [1]
|
FYI I've found and removed a test with an actually-invalid-default-value (see commit 5). That commit may be worth shipping separately. |
There are a lot of bad hacks here (look a commit at a time to peel them apart) but I've got the core use case passing, and there's only really two remaining kinds of test failure:
|
Getting closer... two hacks replaced by a more elegant solution which fixed the enum conversion issues, and #3451 has been extracted into its own PR. Still need to look into the build-schema-from-definition issues. |
963b205
to
84a141c
Compare
Fixes a weird require/load-order issue that showed up while I was trying to validate default values. See the explanation at rmosolgo#3448 (comment)
84a141c
to
efce0dc
Compare
efce0dc
to
e937f95
Compare
e937f95
to
11a4c24
Compare
On consideration, #3459 is annoying and weakens any solution to this problem, but isn't technically blocking it. However, there is one remaining blocking problem which is much trickier: handling default values of type
Originally I thought this was just an issue with schema-first development and @benjie this is basically the "recursion without infinite cycles is hard" problem we were worried about when you wrote the RFC. I think the RFC is still basically correct, and if I were writing a new implementation green-field I could probably make it work, but right now backporting this validation into the existing ruby implementation would seem to require substantial refactoring. OR, maybe, this means that I don't have the time or interest to entirely rewrite how late-bound types work; I've got a few more things to explore, but barring a better solution I'm probably going to drop this. |
For #3248
Still some things TODO