-
Notifications
You must be signed in to change notification settings - Fork 23
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
Feature/format validation errors #598
Merged
Merged
Conversation
This file contains 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
We attempt to choose the most useful errors by doing as follows: - if there is a top-level failures from one of our `:fn` schemas, we just use that one - Otherwise, we search through the errors: - we prefer messages with the longest `:in` values, which means the failure was in more sense more "specific" - if there's only one of those, we take it - otherwise, we take a chunk of errors which share the same `:in`, meaning the same portion of the value failed multiple branches of the schema. We arbitrarily choose the first - we see if those all share some common disjunction farther up the tree. Error messages on `:or`/`:orn`s can be written to express the requirements in one sentence, which we prefer over using the children of that disjunction - if not, we just pick one from the chunk Other changes: - use version of `-resolve-root-error` with two fixes: - ensures `:error/fn`s have access to a correct value. This fixes a bug which was causing `nil` values in error messages - guard against `:invalid-schema` error when root error is due to an extra key not present in the schema - add override that attempts to improve upon invalid-type errors
schema cannot be its own parent
We don't need to make this distinction now that we have special logic to differentiate between type and limit failures
mpoffald
force-pushed
the
feature/format-validation-errors
branch
from
October 24, 2023 19:29
b322250
to
48ac67a
Compare
dpetran
approved these changes
Oct 24, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! Excited to see this come to fruition 🌳
This was referenced Oct 25, 2023
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.
Closes # #312
This PR introduces functionality that takes Malli's validation errors and computes a human-readable string explaining the failure.
At a high level, it does this by using heuristics to select the most "useful" error from among the (typically many) errors, and then uses that error to compute some contextual information to add.
About the heuristics:
:in
values on errors to help us choose, preferring longer ones. The:in
vector contains the path into the specific portion of a value that failed validation. So if someone gives us a map that isn’t quite a valid::where-map
, errors specific to the contents of the map will have the longer:in
values, which will be a more relevant error.:in
s, if there are multiple errors with the same:in
, we search for any:or
/:orn
“parents” of those errors, and prefer those messages to the ones from children errors. I found that it was much simpler to write a nice:error/message
on a disjunction than try to compute one on the fly from the children.Note For this to work well, we should strive to have nice
:error/messages
on ouror
s. I added the ones we needed for the list in #312, plus a few others that occurred to me, but we may still want more. And when we make schema changes, we'll need to update these messages.For this PR, I did not include tests for the specific error strings, since those are likely to be in flux and may prove to be a maintenance nightmare. I did add a repl file containing a bunch of incorrect queries, which I used to develop this feature. I would find this to be useful personally, but if it seems like it wouldn't be for everyone else, I can remove it.
Examples
As of this writing, here's what I get for the error messages from this list (plus a few others):