-
-
Notifications
You must be signed in to change notification settings - Fork 872
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
schemaPath
in ajv.errors
is often incorrect for errors inside $ref
'd schema
#512
Comments
I'm getting a similar problem but without any '#' or multiple schemas. I've a fairly large amount of definitions, some of them cross-referencing each other. One particular instance is a case where I have an object that can be one of two referenced definitions. One of these definitions ('function') requires two properties, "func" and "params", while the other ('connection') requires "location" and "type". Any further information that you need, I'll be happy to provide to the best of my abilities. |
@aapoalas thank you. Some simplified example of your issue would be helpful too, in runkit.com if possible |
Horrah, I actually managed to reproduce this! I was kind of expecting that to not happen with a simpler example but here it is: https://runkit.com/aapoalas/5941134ab79c0b00117f3137 The schema itself is still not too simple, about 60 lines, but the gist of it should be pretty understandable. If you have any further questions, just ask. |
I am trying to use the schema as below and getting the error as "can't resolve reference device from id #" schema:
Could you please tell me what part I am missing here? |
@Mythili007 it’s unrelated to this issue, you reference is incorrect. You may need #/device - but it’s not clear from a partial sample. Please refer to the docs or JSON schema spec or submit a question to stackoverflow. |
I ran into this today with version 6.12.0, and have a much shorter, simpler RunKit example: https://runkit.com/5e68dad1e356eb0014ed2786/5e68dae0e356eb0014ed27af
Removing the |
Related to bug ajv-validator/ajv#512 (comment)
Related to bug ajv-validator/ajv#512 (comment)
What version of Ajv are you using? Does the issue happen if you use the latest version?
4.11.8 and 5.1.5. Yes.
Ajv options object
Only
{ v5: true }
is needed (and only for version 4), in order to have$ref
.JSON Schema
Schemas with a
$ref
that doesn't contain#
or that ends in#/
.Sample data
Data that makes validation fail because of the
$ref
'd schema.Your code
Minimal example:
Validation result, data AFTER validation, error messages
What results did you expect?
For that example, the correct schema path is
'/a#/type'
.A longer example illustrates what happens, and points to a workaround and maybe a correct fix:
A workaround consists of including an empty fragment (as in
{ "$ref": "/a#" }
) when writing the schema. It is not a normalized id, but apparently that doesn't hurt anything.As to fixing it...
I think this is controlled here https://github.com/epoberezkin/ajv/blob/master/lib/dot/ref.jst#L44, but I'm not sure it's the only place. If this guess is correct, then the fix could be as simple as replacing that line with
$it.errSchemaPath = $schema.indexOf('#') != -1 ? $schema : $schema + '#'
.That doesn't address the
#/
case in schema"/d"
. As far as I can tell, https://github.com/epoberezkin/ajv/blob/master/lib/dot/ref.jst#L26 calls https://github.com/epoberezkin/ajv/blob/fde7030a19833273b08e8de879cb2bf149adaf2f/lib/compile/index.js#L170, which in turn calls https://github.com/epoberezkin/ajv/blob/master/lib/compile/resolve.js#L225, which does eliminate terminal#
or#/
. (For example,it.resolve.url('/b', '/a#') == '/a'
andit.resolve.url('/b', '/a#/') == '/a'
, whileit.resolve.url('/b', '/a#something') == '/a#something'
.) Maybe there is some practical way of taking advantage of getting the normalized schema id from the$refVal
in L26? (Normalizing it again seems wasteful...)Are you going to resolve the issue?
It would be cool, but I'm not at all certain I can understand all the ramifications. Specifically, I can't figure what should happen in the non-inlined case (L51 onward), and I can't follow the workings of the refVals (to address also the case with
#/
ending) nor whether the change would have negative impact elsewhere. But maybe with some advice I can navigate it?The text was updated successfully, but these errors were encountered: