fix: add validation of null values with correct order of graphql rule validation #8007
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NamanJain8
approved these changes
Aug 31, 2021
Contributor
NamanJain8
left a comment
There was a problem hiding this comment.
LGTM. It would be good to add an example in the PR description.
aman-bansal
added a commit
that referenced
this pull request
Aug 31, 2021
… validation (#8007) * fix: add validation of null values with correct order of graphql rule validation
kevinmingtarja
pushed a commit
that referenced
this pull request
Aug 30, 2022
…l rule validation (#8007) * fix: add validation of null values with correct order of graphql rule validation
dshekhar95
pushed a commit
that referenced
this pull request
Sep 19, 2022
… validation (#8007) * fix: add validation of null values with correct order of graphql rule validation
dshekhar95
added a commit
that referenced
this pull request
Sep 29, 2022
…phql rule validation (#8333) the previous merge was not squashed, this was the original PR #8320 … validation (#8007) * fix: add validation of null values with correct order of graphql rule validation <!-- Change Github PR Title Your title must be in the following format: - `topic(Area): Feature` - `Topic` must be one of `build|ci|docs|feat|fix|perf|refactor|chore|test` Sample Titles: - `feat(Enterprise)`: Backups can now get credentials from IAM - `fix(Query)`: Skipping floats that cannot be Marshalled in JSON - `perf: [Breaking]` json encoding is now 35% faster if SIMD is present - `chore`: all chores/tests will be excluded from the CHANGELOG --> ## Problem <!-- Please add a description with these things: 1. Explain the problem by providing a good description. 2. If it fixes any GitHub issues, say "Fixes #GitHubIssue". 3. If it corresponds to a Jira issue, say "Fixes DGRAPH-###". 4. If this is a breaking change, please prefix `[Breaking]` in the title. In the description, please put a note with exactly who these changes are breaking for. --> ## Solution <!-- Please add a description with these things: 1. Explain the solution to make it easier to review the PR. 2. Make it easier for the reviewer by describing complex sections with comments. --> Co-authored-by: aman bansal <[email protected]> Co-authored-by: dshekhar95 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes the bug mentioned in https://discuss.dgraph.io/t/no-input-field-null-validation-on-non-nullable-fields/14085.
Issue is suppose a schema is defined type Task { name: String! }.
Now dgraph generates the mutation schema as follows:
Now while executing mutation, graphql accept both arrays and single object as input. This means:
both the above mutation are valid. But dgraph after the validation assumes that it will always be an list. This leads to some panics in the past and hence to make it compliant we added listInputCoercion which will change the value to List if needed so that there wont be any issue afterwards. But this leads to other bugs where few of the validations were getting skipped. For example this mutation will fail
because listInputCoercion changes the {} to [{}] and this will be skipped by the data type validation because of arrays. Hence
an empty data object will be inserted leading to a corrupted database.
This PR adds the order to the execution of rule validations and listInputCoercion is placed in the end so that when the rules are getting executed, all validations are executed first and value change is executed last so that it wont mess up the queries again
This change is