Support $dynamicAnchor and $recursiveAnchor in any schema location (not only root)

[essential-randomness]

What version of Ajv are you using? Does the issue happen if you use the latest version?
8.6.2, which should be the latest

Ajv options object

{
    allErrors: true, 
    validateFormats: false, 
    strictSchema: false, 
    strictTypes: false
}

See OAI/OpenAPI-Specification#2489 for a discussion on the options.

JSON Schema

The OpenAPI 3.1 schema defined here: https://github.com/OAI/OpenAPI-Specification/blob/main/schemas/v3.1/schema.json

I'm not proficient enough to make this a minimal reproduction example.

Sample data

the OpenApi v3.1 webhook example here: https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.1/webhook-example.json

Your code

See: https://runkit.com/essential-randomness/612d87df07ae0a00092a3492.

This simply call ajv with the given options, passes the OpenApiv3.1 schema and tries to validate the OpenApi Webhook example:

Validation result, data AFTER validation, error messages

Invalid: 
data/webhooks/newPet/post/requestBody/content/application~1json/schema must NOT have unevaluated properties, 
data/webhooks/newPet/post/requestBody must match "else" schema,
data/webhooks/newPet must match "else" schema, 
data/components/schemas/Pet must NOT have unevaluated properties, 
data/components/schemas/Pet must NOT have unevaluated properties

What results did you expect? I would expect the validation to pass.

Are you going to resolve the issue?

I would like some help understanding whether the issue is in AJV or the OpenAPI specification. I was trying to add support for OpenAPIv3.1 to some JavaScript libraries that use AJV, but unfortunately this makes it impossible.

There's many libraries that will (hopefully) want to make this switch at some point, but I couldn't find anyone who has already done it or has published an investigation of what's needed to get this working. If anyone is ever going to fix it, understanding what's going on would be the first step :)

[epoberezkin]

I am sorry, I will not be able to investigate the problem with such a large schema / data sample. Please reduce it to a minimum size (definitely under 20 lines in the schema) when it still demonstrates the issue - either by removing all properties from the schema/data that are not causing issues (and any other parts of the schema) or by starting from scratch, trying to build the example that you think should work but doesn’t.

[essential-randomness]

I asked the OpenAPI folks for help and they provided a minimal reproduction:

schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",

  "type": "object",
  "properties": {
    "schema": { "$dynamicRef": "#meta" }
  },
  "unevaluatedProperties": false,

  "$defs": {
    "schema": {
      "$dynamicAnchor": "meta",
      "type": ["object", "boolean"]
    }
  }
}

instance

{
  "schema": { "type": "string" }
}

According to them, this is a bug in AJV: "It appears that the $dynamicRef is resolving to the root of the schema rather than /$defs/schema where the $dynamicAnchor is located".

[epoberezkin]

Thanks, so it’s a duplicate of #1573

[epoberezkin]

• It should compile and correctly validate the sample schema
• it should compile and correctly validate against OpenAPI schema
• it should pass two currently skipped tests (they are skipped via test command parameters in package.json)
• tests (sample schema, OpenAPI schema)

[Mikescops]

Hello @epoberezkin, do you have any insights about the progress of this issue?

[srgg]

Is there any progress on that?

[epoberezkin]

It’s non-trivial, but maybe some time this year I will find a day…

Happy to offer a bounty from Ajv open collective for thorough implementation of this thing - say $500-1000 - with tests, docs, etc.

Let me know if you are interested.

[jdesrosiers]

It’s non-trivial

This might be a smaller effort than you think. Most implementers start off thinking it's hard, and then the actual implementation ends up being a very simple. Given how much of this feature ajv already supports, it's hard to imagine it would take much to get it over the finish line.

I say this as someone who has implemented this feature and has discussed it's implementation with several other implementers, but I don't know this code base and what unique challenges it might face, so you experience may vary. I'm just sharing my experience in case it's helpful.

[epoberezkin]

You are probably right...

[OlivierCuyp]

Not sure I could help with my little knowledge of the issue...
I just wanted to mark my interest on this issue.
It would be so great to have OpenApi 3.1.0 validation.

[jcmosc]

Any progress on this? Is the bounty offer still open?

[thegu5]

What's the status on this?

[Jackman3005]

From what I can tell this is still the only holdup for express-openapi-validator from supporting OAS 3.1. Pressure feels like it's building as other libraries are picking up support for OAS 3.1. It's getting difficult to get interoperability between libraries when you have multiple downstream consumers of your spec and are trying to accomplish different features. Right now all other libraries I am using are ready and support OAS 3.1 (at least the parts I need) and express-openapi-validator is the holdout preventing me from adopting it entirely.

[jasoniangreen]

I am going to take a look at this, but I have a lot of context to get up to speed with first. I assume it is still a desired fix :)