yaml-language-server icon indicating copy to clipboard operation
yaml-language-server copied to clipboard

Schema reference in URL hash can’t be resolved

Open remcohaszing opened this issue 3 years ago • 12 comments

Describe the bug

When a schema uri uses a hash to select a nested schema, the language server can no longer resolve it. This was working in yaml-language-server 1.1.0 and below. It first appeared in 1.1.1.

Expected Behavior

A nested schema can be referenced using a URL hash.

Current Behavior

The following error occurs in VS Code:

[{
	"resource": "/home/remco/Projects/appsemble/apps/person/app-definition.yaml",
	"owner": "_generated_diagnostic_collection_name_#0",
	"code": "768",
	"severity": 8,
	"message": "$ref '%2Fcomponents%2Fschemas%2FAppDefinition' in 'https://appsemble.app/api.json' can not be resolved.",
	"source": "YAML",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 1,
	"endColumn": 2
}]

Steps to Reproduce

  1. Create a file named app-definition.yaml.
  2. Open it in VS Code
  3. Enter at least one character

Environment

  • [ ] Windows
  • [ ] Mac
  • [x] Linux
  • [x] other (please specify) remcohaszing/monaco-yaml#126 (demo)

remcohaszing avatar Nov 11 '21 10:11 remcohaszing

This is a real blocker for me, so I decided to try and solve it myself.

I am not able to reproduce this issue by debugging by following these steps, as in: It works as expected then using whatever versions. And yes, I really made sure I was using the correct versions, ran yarn and yarn compile in both projects in the correct order after doing a git checkout of several tags I tried.

Instead I decided to give it a try with vim-lsp. For this I used the tag 1.2.2.

I use vim-lsp-settings. This reproduces the error. I use the following vimrc snippet:

call plug#begin('~/.vim/plugged')

Plug 'prabirshrestha/vim-lsp'
Plug 'mattn/vim-lsp-settings'

call plug#end()

However, if I use a local clone of yaml-language-server, I can once again not reproduce the issue. For this I used the following vimrc snippet:

au User lsp_setup call lsp#register_server({
  \ 'name': 'yaml',
  \ 'cmd': {server_info->['node', 'out/server/src/server.js', '--stdio']},
  \ 'allowlist': ['yaml'],
\})

call plug#begin('~/.vim/plugged')

Plug 'prabirshrestha/vim-lsp'

call plug#end()

remcohaszing avatar Jan 06 '22 15:01 remcohaszing

I narrowed it down to an upstream bug introduced in [email protected]. It works as expected in version 4.1.8. This also explains why the bug exists in production, but not in development. According to the semver range (^4.1.7) the newest version (4.1.10) may be used, but in development yarn.lock locks it to 4.1.7.

remcohaszing avatar Jan 07 '22 09:01 remcohaszing

@remcohaszing Looks like it is resolved, could we close this?

evidolob avatar Jan 27 '22 12:01 evidolob

That really depends on your stance on the matter. A temporary workaround has been applied. I don’t know if that means the issue is resolved.

One could argue the issue is gone for now, so the issue can be closed.

One could also argue this issue is relevant as long as microsoft/vscode-json-languageservice#123 hasn’t been fixed and released.

I’ll let you decide whether you want to close this issue or not. Just please be careful when updating that dependency. :)

remcohaszing avatar Jan 27 '22 12:01 remcohaszing

We are going to have to make the dependency update sooner or later.

@aeschli, any hints if we can expect a resolution to https://github.com/microsoft/vscode-json-languageservice/issues/123 soon?

gorkem avatar Jan 27 '22 23:01 gorkem

I thought I would chime in that I am experiencing this same issue when using the redhat.vscode-yaml VS Code extension. I can create a different issue in this repo or the redhat.vscode-yaml repo if someone thinks it belongs there instead. The main difference I've observed compared to the original issue is that the error occurs on all versions I've tested. VS Code

Version: 1.67.1 (system setup)
Commit: da15b6fd3ef856477bf6f4fb29ba1b7af717770d
Date: 2022-05-06T12:37:03.389Z
Electron: 17.4.1
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: 9.8.177.13-electron.0
OS: Windows_NT x64 10.0.19044

Describe the bug

When a schema uri uses a hash to select a nested schema, the language server can no longer resolve it. This unexpected behavior is experienced in versions 1.1.0, 1.1.1, and the latest 1.7.0 of redhat.vscode-yaml VS Code extension.

Expected Behavior

A nested schema can be referenced using a URL hash.

Current Behavior

The following error occurs in VS Code Output pane for 'YAML Support' with Trace enabled:

[Trace - 2:12:32 PM] Sending request 'textDocument/codeAction - (63)'.
Params: {
    "textDocument": {
        "uri": "file:///c%3A/Users/TestUser/Documents/Scripts/Python/test.yaml"
    },
    "range": {
        "start": {
            "line": 2,
            "character": 0
        },
        "end": {
            "line": 2,
            "character": 0
        }
    },
    "context": {
        "diagnostics": [
            {
                "range": {
                    "start": {
                        "line": 2,
                        "character": 0
                    },
                    "end": {
                        "line": 2,
                        "character": 1
                    }
                },
                "message": "$ref '/definitions/schemaArray' in 'https://raw.githubusercontent.com/StackStorm/st2/master/contrib/schemas/action.json' can not be resolved.",
                "code": 768,
                "severity": 1,
                "source": "YAML"
            }
        ]
    }
}

Steps to Reproduce

Create a YAML file with the below content:

# yaml-language-server: $schema=https://raw.githubusercontent.com/StackStorm/st2/master/contrib/schemas/action.json
---
name: "hello"

Open it in VS Code Observe unexpected behavior 20220517_141526_Code

ShawnHardwick avatar May 17 '22 18:05 ShawnHardwick

I've reduced the issue in my previous comment. I've been unable to get the the $ref funtionality to resolve correctly in the redhat.vscode-yamlVS Code extension.

Doesn't work

{
    "id": "http://json-schema.org/draft-04/schema#",
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "Action",
    "description": "An activity that happens as a response to the external event.",
    "type": "object",
    "properties": {
		"maxLength": {
			"$ref": "#/definitions/positiveInteger"
		}
	},
    "additionalProperties": false
}

Works

{
    "id": "http://json-schema.org/draft-04/schema#",
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "Action",
    "description": "An activity that happens as a response to the external event.",
    "type": "object",
    "properties": {
		"maxLength": {
			"$ref": "http://json-schema.org/draft-04/schema#/definitions/positiveInteger"
		}
	},
    "additionalProperties": false
}

ShawnHardwick avatar May 17 '22 20:05 ShawnHardwick

@ShawnHardwick Yes, the vscode-json-languageservice doesn't yet properly handle the id property. Actually, I wasn't aware that one can use that to extend an existing schema. Nothing has changed here, this never worked.

aeschli avatar May 18 '22 07:05 aeschli

@gorkem @remcohaszing I'm quite sure the original issue has been fixed. https://github.com/microsoft/vscode-json-languageservice/issues/123 is not a proper reproduction of the problem as we never supported $schema with fragments,

aeschli avatar May 18 '22 07:05 aeschli

@aeschli Thanks for the clarification. I couldn't find any references anywhere that id was not supported in the VS Code extension or yaml-language-server repos. I didn't think that the vscode-json-languageservice repo would be where it was implemented. At least I have a workaround for now.

ShawnHardwick avatar May 18 '22 13:05 ShawnHardwick

I've noticed that for some schema URLs the hash does resolve correctly but for others it doesn't. Example:

# yaml-language-server: $schema=https://spec.openapis.org/oas/3.0/schema/2021-09-28#/definitions/PathItem
# yaml-language-server: $schema=https://spec.openapis.org/oas/3.1/schema/2022-10-07#/$defs/path-item

The first line will work but the second one doesn't. The only differences I can see are that the second URL contains characters such as $ and -.

icedream avatar Jan 24 '24 13:01 icedream