-
Notifications
You must be signed in to change notification settings - Fork 50
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
Error identification on complex schemas #55
Comments
I'm sorry, I think I need a simpler example to get your idea. Could you make a sample schema/data/filtering condition? |
Error readability is a relevant topic for JSON Schema community, here is a relevant hot issue fyi: json-schema-org/json-schema-spec#396 Hopefully with next draft we will come up with usable standard solution, and your case might contribute. |
Here's a short example:
The error returned by the script is:
There are 2 'required property missing' and one 'additional properties not allowed' errors. One idea could be to filter out all the 'required property missing' errors where the path is '#->properties:test->anyOf[*'. |
As a matter of fact in this specific example it should be possible to identify the "testC" schema as the source of the error and output just that reference, am I wrong? |
Thank you for example, I agree flexible filtering mechanism can be indeed helpful for advanced user. I'll try to implement that. |
Hello,
I have some problems when trying to identify errors on complex schemas.
Suppose you have a "anyOf" clause with many items, for example you can look at the AWS Cloud Formation schema example here https://raw.githubusercontent.com/awslabs/goformation/master/schema/cloudformation.schema.json
.
The "Resources" property is an "anyOf" with many items. If you create a json document where Resources entry (ie "AWS::AmazonMQ::Broker") has a mystyped property (ie "AutoMinorVersionUpgrade" not a boolean) it's very difficult to find where the error is because the library outputs (correctly) a "no valid results for anyOf" error and in the subErrors property you will find a list of all the possible errors.
This list is difficult to parse so finding the "right" error is difficult.
I know this is strictly related to the specific schema so a generic method can be difficult to implement, a suggestion could be to add a parseable property to the errors so that, for example, it's possible to add application specific code to restrict the errors list.
Referring to the example above I could filter all the Resources subschemas that are not "AWS::AmazonMQ::Broker" by inspecting error type, dataPointer and processingPath.
Thanks,
Frank
The text was updated successfully, but these errors were encountered: