The server cannot be started if rootUri is a WSL path

[alisa-zobova]

Path to rootUri is correct WSL path, but I got error on initialization:

org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Request initialize failed with message: [UriError]: If a URI does not contain an authority component, then the path cannot begin with two slash characters ("//")

Verbose trace:

[Trace - 08:43:12] Sending request 'initialize - (1)'.
Params: {
  "processId": 9900,
  "rootPath": "//wsl.localhost/Ubuntu/home/alisa/Work/House Caddy/caddy-house-backend",
  "rootUri": "file:////wsl.localhost/Ubuntu/home/alisa/Work/House%20Caddy/caddy-house-backend",
  "capabilities": {
    "workspace": {
      "applyEdit": true,
      "workspaceEdit": {
        "documentChanges": true,
        "resourceOperations": [
          "create",
          "delete",
          "rename"
        ]
      },
      "didChangeConfiguration": {
        "dynamicRegistration": true
      },
      "didChangeWatchedFiles": {
        "dynamicRegistration": true
      },
      "symbol": {},
      "executeCommand": {
        "dynamicRegistration": true
      },
      "workspaceFolders": true,
      "configuration": true,
      "semanticTokens": {
        "refreshSupport": true
      },
      "codeLens": {
        "refreshSupport": true
      },
      "fileOperations": {
        "didRename": true,
        "willRename": true,
        "dynamicRegistration": true
      },
      "inlayHint": {
        "refreshSupport": true
      }
    },
    "textDocument": {
      "synchronization": {
        "willSave": true,
        "willSaveWaitUntil": true,
        "didSave": true
      },
      "completion": {
        "completionItem": {
          "snippetSupport": true,
          "documentationFormat": [
            "markdown",
            "plaintext"
          ],
          "deprecatedSupport": true,
          "resolveSupport": {
            "properties": [
              "documentation",
              "detail",
              "additionalTextEdits"
            ]
          },
          "insertTextModeSupport": {
            "valueSet": [
              1,
              2
            ]
          },
          "labelDetailsSupport": true
        },
        "completionList": {
          "itemDefaults": [
            "editRange"
          ]
        },
        "dynamicRegistration": true
      },
      "hover": {
        "contentFormat": [
          "markdown",
          "plaintext"
        ],
        "dynamicRegistration": true
      },
      "signatureHelp": {
        "signatureInformation": {
          "parameterInformation": {
            "labelOffsetSupport": true
          }
        },
        "dynamicRegistration": true
      },
      "references": {
        "dynamicRegistration": true
      },
      "documentHighlight": {
        "dynamicRegistration": true
      },
      "documentSymbol": {
        "symbolKind": {
          "valueSet": [
            18,
            17,
            5,
            14,
            9,
            10,
            22,
            24,
            8,
            1,
            12,
            11,
            20,
            6,
            2,
            3,
            21,
            16,
            19,
            25,
            4,
            7,
            15,
            23,
            26,
            13
          ]
        },
        "hierarchicalDocumentSymbolSupport": true,
        "dynamicRegistration": true
      },
      "formatting": {
        "dynamicRegistration": true
      },
      "rangeFormatting": {
        "dynamicRegistration": true
      },
      "declaration": {
        "linkSupport": true,
        "dynamicRegistration": true
      },
      "definition": {
        "linkSupport": true,
        "dynamicRegistration": true
      },
      "typeDefinition": {
        "linkSupport": true,
        "dynamicRegistration": true
      },
      "implementation": {
        "linkSupport": true,
        "dynamicRegistration": true
      },
      "codeAction": {
        "codeActionLiteralSupport": {
          "codeActionKind": {
            "valueSet": [
              "quickfix",
              "refactor",
              "refactor.extract",
              "refactor.inline",
              "refactor.rewrite",
              "source",
              "source.organizeImports"
            ]
          }
        },
        "dataSupport": true,
        "resolveSupport": {
          "properties": [
            "edit"
          ]
        },
        "dynamicRegistration": true
      },
      "codeLens": {
        "dynamicRegistration": true
      },
      "documentLink": {
        "dynamicRegistration": true
      },
      "colorProvider": {
        "dynamicRegistration": true
      },
      "rename": {
        "prepareSupport": true,
        "dynamicRegistration": true
      },
      "publishDiagnostics": {
        "relatedInformation": true,
        "tagSupport": {
          "valueSet": [
            1,
            2
          ]
        },
        "codeDescriptionSupport": true,
        "dataSupport": true
      },
      "foldingRange": {
        "dynamicRegistration": true
      },
      "typeHierarchy": {
        "dynamicRegistration": true
      },
      "callHierarchy": {
        "dynamicRegistration": true
      },
      "semanticTokens": {
        "requests": {
          "range": false,
          "full": true
        },
        "tokenTypes": [
          "namespace",
          "type",
          "class",
          "enum",
          "interface",
          "struct",
          "typeParameter",
          "parameter",
          "variable",
          "property",
          "enumMember",
          "event",
          "function",
          "method",
          "macro",
          "keyword",
          "modifier",
          "comment",
          "string",
          "number",
          "regexp",
          "operator",
          "decorator",
          "label"
        ],
        "tokenModifiers": [
          "declaration",
          "definition",
          "readonly",
          "static"
        ],
        "formats": [
          "relative"
        ],
        "multilineTokenSupport": true,
        "serverCancelSupport": true,
        "dynamicRegistration": true
      },
      "inlayHint": {
        "dynamicRegistration": true
      },
      "diagnostic": {
        "relatedDocumentSupport": true,
        "dynamicRegistration": true
      }
    },
    "window": {
      "workDoneProgress": true,
      "showMessage": {},
      "showDocument": {
        "support": true
      }
    },
    "general": {
      "staleRequestSupport": {
        "cancel": true,
        "retryOnContentModified": []
      },
      "positionEncodings": [
        "utf-16"
      ]
    }
  },
  "clientInfo": {
    "name": "PyCharm 2025.2.0.1",
    "version": "PyCharm (build PY-252.23892.515)"
  },
  "trace": "off",
  "workspaceFolders": [
    {
      "uri": "file:////wsl.localhost/Ubuntu/home/alisa/Work/House%20Caddy/caddy-house-backend",
      "name": "caddy-house-backend"
    }
  ]
}


org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Request initialize failed with message: [UriError]: If a URI does not contain an authority component, then the path cannot begin with two slash characters ("//")
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleResponse(RemoteEndpoint.java:209)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:193)
	at com.redhat.devtools.lsp4ij.LanguageServerWrapper.lambda$start$5(LanguageServerWrapper.java:378)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1491)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2073)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2035)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)
[Trace - 08:43:13] Received notification 'window/logMessage'
Params: {
  "type": 3,
  "message": "Pyright language server 1.1.404 starting"
}


[Trace - 08:43:13] Received notification 'window/logMessage'
Params: {
  "type": 3,
  "message": "Server root directory: file:///c%3A/Users/zobov/AppData/Local/Programs/Python/Python313/Lib/site-packages/pyright/dist/dist"
}


[Trace - 08:43:13] Received response 'initialize - (1)' in 1003ms.
No response returned.
Error: {
  "code": -32603,
  "message": "Request initialize failed with message: [UriError]: If a URI does not contain an authority component, then the path cannot begin with two slash characters (\"//\")"
}

[Trace - 08:43:13] Sending request 'shutdown - (2)'.
Params: null


[Trace - 08:43:13] Received response 'shutdown - (2)' in 0ms.
No response returned.


[Trace - 08:43:13] Sending notification 'exit'
Params: null

[rcjsuen]

I do wonder how invalid URIs should be handled. I've opened microsoft/language-server-protocol#2154 questioning how best to handle these cases.

@alisa-zobova What version of WSL are you on? How would one reproduce this?

[angelozerr]

@alisa-zobova this error comes from your language server and doesnt comes from LSP4IJ or lsp4j.

I suggest that yiu report your issue at the language server repository.

[angelozerr]

@alisa-zobova which language server are you using?

You are using as user defined or with an IJ plugin?

If it is the case 2, you could override the initialize request. If it exists a vscode extension which uses your language server, I suggest that you try it.

If there are no errors, I suggest that you compare this lsp request trace with vscode trace

[tim-sh]

We also saw a similar problem on Windows 11 (I suppose) when running IntelliJ IDEA on Windows and opening a project living in WSL by choosing the 'WSL' category on the bottom left in the Windows file/folder picker.

(file:////hostname/path URLs seem to be invalid, strictly speaking, but used in the wild nevertheless. I read that Java tends to use this variant.)

In our case (SAP CDS language server packed by our plugin, which relies on LSP4IJ) we had trouble normalizeing such paths in Node.js. We've started working on a fix in the server.

Should LSP4IJ 'standardize' such paths (drop two slashes), what do you think?

[angelozerr]

In our case (SAP CDS language server packed by our plugin, which relies on LSP4IJ) we had trouble normalizeing such paths in Node.js. We've started working on a fix in the server.

Or with LSP4IJ you can override any initialize params filelds by overriding LSPClientFeatures#initializeParams(InitializeParams initializeParams)

Should LSP4IJ 'standardize' such paths (drop two slashes), what do you think?

I don't know WSL, so it is difficult for me to know what is the best behavior. @InSyncWithFoo I believe you have supported WSL in your plugins, do you think we could improve LSP4IJ to support it correctly?

[tim-sh]

Or with LSP4IJ you can override any initialize params filelds by overriding LSPClientFeatures#initializeParams(InitializeParams initializeParams)

Might be an easier solution if the client can cope when receiving such modified paths back from the server. Thanks for the hint, we should try that. 👍

[alisa-zobova]

Hi)

@rcjsuen WSL version info:

wsl --version
WSL version: 2.3.26.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.4946

@angelozerr I am using Pycharm plugin for Pyright. In VSCode, the server for Pyright works fine in WSL shell. But it seems to me that the extension for WSL somehow more clearly separates Windows and WSL in VSCode, so there is no such confusion with file paths. Maybe it really is worth comparing the traces. I'll give it a try.

As for overriding LSPClientFeatures#initializeParams(InitializeParams initializeParams) - it's an interesting idea, also worth trying, thanks)

@tim-sh I haven't encountered this before, so I'm not sure if it would be right to “standardize” such paths. Maybe there is someone who has also encountered this and knows how to solve it without breaking the path, but at the same time making it valid for the server?

[rcjsuen]

I haven't encountered this before, so I'm not sure if it would be right to “standardize” such paths. Maybe there is someone who has also encountered this and knows how to solve it without breaking the path, but at the same time making it valid for the server?

In our case, I realized that on WSL 1 you can get VS Code to open and send a rootUri with file://wsl%24/docker-desktop/tmp (docker/vscode-extension#165) which crashed our language server. I ended up refactoring all the code in the language server to handle such a URI.

[InSyncWithFoo]

@angelozerr My plugin also has this problem. I think the reason none of my users have encountered it so far is because most of them use PyCharm Professional with both native WSL and LSP support, and thus they won't have a need to install LSP4IJ.

[InSyncWithFoo]

In case it might help, here's the initialize request as sent by the native client (excluding capabilities):

{
	"jsonrpc": "2.0",
	"id": "1",
	"method": "initialize",
	"params": {
		"processId": null,
		"rootPath": "//wsl$/Ubuntu/home/insync/project",
		"rootUri": "file:///home/insync/project",
		"clientInfo": {
			"name": "PyCharm",
			"version": "252.25557.70"
		},
		"workspaceFolders": [
			{
				"uri": "file:///home/insync/project",
				"name": "project"
			}
		]
	}
}

I'm on Windows 10, hence wsl$, but Windows 11 might use wsl.localhost instead.

[angelozerr]

@InSyncWithFoo if I understand correctly, your language server (pyright) can support WSL file uri?

[InSyncWithFoo]

@angelozerr What do you mean by "support WSL file uri"? So far I have been asking my users to install Pyright within WSL if their project is also WSL-based. GeneralCommandLine runs Pyright on Windows, however, so I have to convert URIs and such. As for whether Pyright itself would work if it were installed on Windows but the project was on WSL, I don't know.

[angelozerr]

@angelozerr I am using Pycharm plugin for Pyright. In VSCode, the server for Pyright works fine in WSL shell. But it seems to me that the extension for WSL somehow more clearly separates Windows and WSL in VSCode, so there is no such confusion with file paths. Maybe it really is worth comparing the traces. I'll give it a try.

Exactly, please provide vscode trace in order we can compare them with LSP4IJ

[tim-sh]

As mentioned, we were facing a similar problem, which I now investigated in more depth including some trials, with the following tentative conclusions.

Above, @alisa-zobova and @InSyncWithFoo each quoted an invalid 2-slash rootPath starting with //wsl (continued $ or .localhost, both suffixes being equivalent).

Such values might have been derived by flipping the backslashes in a valid Windows path:

      \\wsl.localhost\distro\some\path.txt

Side note: other valid notations include:

               \\wsl$\distro\some\path.txt
\\UNC\?\wsl.localhost\distro\some\path.txt
         \\UNC\?\wsl$\distro\some\path.txt

The 2-slash path form might also have been derived by omitting the file:// prefix in 4-slash URIs such as the one Alisa quoted, starting with file:////wsl.localhost/.

In terms of occurrence, we are observing that LSP4IJ does send the mentioned path and URI forms, e.g.:

{
  "rootPath": "//wsl.localhost/distro/some/path.txt",
  "rootUri": "file:////wsl.localhost/distro/some/path.txt"
}

So in our code, when the LSP server initializes, since we prefer to rely on a URI anyway, we simply convert the URI into a UNC path, which does work.

HTH, Tim