JSON schema validation does not work for array items when in a combined schema

[shuebner]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.88.1
• OS Version: Windows 10 Enterprise 10.0.19045

Steps to Reproduce:

1. Define a JSON schema with array tuple validation:

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type": "array",
    "items": [
        {
            "type": "string"
        },
        {
            "type": "integer"
        }
    ]
}

2. Let VSCode validate an invalid file:

[
    42,
    "foo"
]

3. Observe that VSCode does not show any error even though the file is not valid against the schema.

[aeschli]

This works for me.
Did you add the schema association?

[shuebner]

Yes I did. I also did some more digging and found that the culprit is an extension after all: 42crunch.vscode-openapi.

When I re-ran the extension bisect, it found something this time.
But: it incorrectly identified the extension redhat.vscode-yaml.
42crunch.vscode-openapi does depend on redhat.vscode-yaml, so not sure what was going on there during bisect.

With 42crunch.vscode-openapi disabled and VSCode restarted, validation does work correctly.

I created an issue there: 42Crunch/vscode-openapi#272

[ak1394]

Hi! Author of 42crunch.vscode-openapi extension here.

I wonder if this could this be a VS Code regression? The extension indeed contributes an openapi.json schema:

"jsonValidation": [
      {
        "fileMatch": "*.json",
        "url": "./schema/generated/openapi.json"
      }
...

The openapi.json contains schema, that applies Swagger or OpenAPI 3.0.X schemas depending on a JSON file contents:

{
 "$schema": "http://json-schema.org/draft-07/schema#",
  "dependencies": {
    "swagger": {
      "if": {
         "properties": { "swagger": { "const": "2.0" } }
      },
      "then":  {"$ref": "openapi-2.0.json" }
    },
    "openapi": {
      "if": {
         "properties": { "openapi": { "pattern": "^3\\.0\\.\\d(-.+)?$" } }
      },
      "then":  {"$ref": "openapi-3.0-2019-04-02.json" }
    }
  }
}

The example json file above does not match openapi.json schema. Presumably VS Code should continue the validation, use the schema from user's settings.json and report a validation error. However this does not happen.

I should note, that the way we contribute the openapi schema in the extension is not new, and has been like that for a while. If needed, I can find past discussion with VS Code devs, related to the fact that VS Code has no way to dynamically set the schema based on file contents, forcing us to use "fileMatch": "*.json".

[shuebner]

Note that VSCode is doing some validation even in my repro.
If you change the validated JSON from an array to an object it correctly marks it as invalid with "array expected".
I use JSON validation a lot and have used the same extension set for some time and never experienced any problems.
Maybe the issue is specific to this schema array case.

[aeschli]

Registering a schema for "fileMatch": "*.json", means that it will be applied to all json files.

The schema validation service looks for all schemas that match a given file name. if there are multiple ones, it combines them with a anyOf.
Your schema result true for all schemas, that's why the example now also is valid.

[shuebner]

@aeschli Then how do you explain that a JSON object will still get validation errors? And that all my other JSON schema validations work just fine?

[ak1394]

@aeschli Should it be using allOf instead? Else, are there any plans to allow extensions to contribute schemas dynamically, similar to how it's done in redhat.vscode-yamls registerContributor() API?

[aeschli]

Yes, sorry, my bad, ignore my comment.
It's allOf. It is strange that there are no errors reported, I'm looking into it.
No, there are currently no plans for an API like redhat.vscode-yaml has it.

[aeschli]

I found the problem.
The "items" property semantics have changed in draft 2020. When we create the allOf array we happen to switch to draft 2020 when we combine a schema, regardless of the schema that was specified in the subschema.

-> It's a bug in the json-languageservice on how the current schema version is evaluated