Fix key validator false negatives on empty collections #363
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.
What was happening?
As described in #349 and #355, when using
validate_keys = true
, there are false negatives when the schema encounters unexpected keys where the value is an empty array or -hash, or an array with only primitives.This was happening because the recursively defined
KeyValidator#key_paths
did not handle the cases where there was nothing to recurse over. (The correct behaviour would be to instantly return the key.)The output of this method is what is subsequently checked against the key map, but with the relevant keys missing, the validation logic would overlook these unexpected keys.
How does this fix it?
What is the impact?
This change affects only private APIs, but the obvious "side effect" is that the bug is fixed, and anyone whose application incidentally works because unexpected keys were ignored, might start seeing errors in their application after upgrading.
Limitations
There was a related, but separate, issue highlighted in #355. For nested hashes, the error is tacked onto the innermost hash, rather than on the first key that is unexpected. After having a quick look I decided to not address that in this same PR, as the changes are quite involved, and probably deserve their own PR.