Subschema mappings wrongly assign the parent schema file

[ssbarnea]

Describe the bug

When using subschemas, this extension will end-up trying to validate the documents using both the subschema and the main schema bundle file, which obviously will not pass.

By subschema, I mean using the documented in-document bookmarking for referring to a specific definition from within a schema file.

For example https://raw.githubusercontent.com/ansible/schemas/main/f/ansible.json#/definitions/playbook should load ansible.json schema file and use the playbook definition from it.

AFAIK, all validators are able to process schemas like this and apparently even vscode-yaml, to some extend.

For example we tested with both ajv and the validator used by Microsoft in vscode and both work as expected.

Expected Behavior

Configuring a subschema should not have undesired side effects like attempt to use the main schema file for validation.

In our example that schema file does only have definitions in it, which is still perfectly fine for a schema file that is never expected to be used without a subschema selector. Still, extension does seems to not like the No content. aspect of it.

Current Behavior

This shows that the subschema is loaded correctly because the header line display the subschema name and not the title of the whole bundle.

Still, at the same time a problem is identified:

Problems loading reference 'schemaservice://combinedschema/f/ansible.json#/definitions/tasks': Unable to load schema from 'schemaservice://combinedschema/f/ansible.json': No content.

Steps to Reproduce

1. Configure a subschmema mapping like "https://raw.githubusercontent.com/ansible/schemas/main/f/ansible.json#/definitions/playbook": ['playbook.yml']
2. Open 'playbook.yml' and observe the attempt to use two schemas, one correct one and one incorrect, the one without a "#" url.

So far I was not able to find a workaround yet.

[ssbarnea]

This might also be caused by #453 but in our case the problem is more serious, as we never configured relative paths for schemas, and we have no workaround to make it work.

The code throwing this error from

yaml-language-server/src/languageservice/services/yamlSchemaService.ts

Lines 623 to 631 in 360c038

	if (unresolvedJsonSchema.errors && unresolvedJsonSchema.schema === undefined) {
	return requestService(schemaUri).then(
	(content) => {
	if (!content) {
	const errorMessage = localize(
	'json.schema.nocontent',
	"Unable to load schema from '{0}': No content.",
	toDisplayString(schemaUri)
	);

also looks buggy because it fails to display the errors that caused the load failure, even if they are clearly not empty.

[ssbarnea]

Based of further testing I am now starting to believe that this bug might appear only on projects that use relative paths, like our schemas project itself.

See https://github.com/ansible/schemas/blob/main/.vscode/settings.json#L18-L22

As ability to test the schema changes directly into the editor is essential during development, we need to find a solution for this problem. Any ideas?

[ssbarnea]

Closing it because I am unable to reproduce it today but I suspect it was caused by use or relative paths.

[metal3d]

@ssbarnea you can see neoclide/coc-yaml#64 to reproduce