yaml.schemas setting: breaking regression when using encoded file URLs on Windows

[phaumer]

Describe the bug

In our VS Code extension we are programmatically updating the "yaml.schema" setting when your extension is installed to point to a local schema that ships with our extension to support offline usage. We use the standard VS Code API to serialize the schema URL with

resultUrl = vscode.Uri.file(absoluteSchemaPath).toString();

This returns in Windows a file URL that encodes the colon such as this: file:///c%3A/Users/user1/.vscode/extensions/ibm.zopeneditor-6.6.1/resources/zapp-schema-1.10.2.json

This used to work for years, but a recent update to the extension must have broken this. It now requires to use : instead of %3A. However, both are valid URL.

Expected Behavior

Support both : and %3A

Current Behavior

The schema is not found

Steps to Reproduce

1. On Windows add a file URL with a url encoded schema location
2. Open a yaml file that would use the schema

Environment

• Windows
• Mac
• Linux
• other (please specify)

[shin19991207]

Thanks for reporting this. I wasn’t able to reproduce the exact issue where a local schema fails to resolve because the Windows drive colon is encoded as %3A. In my testing (on both Mac and a Windows VM), both encoded and unencoded file URIs resolve successfully.

However, I found a related schema-priority bug: the URI was normalized when registering the schema but not when recording its priority. As a result, an encoded schema configured through yaml.schemas could incorrectly lose priority to another matching schema. I fixed this priority issue in redhat-developer/yaml-language-server#1312.

Could you please test the PR in the environment where you encountered the problem and confirm whether it resolves the issue? Or does it still exist?