Cannot start metals server on macOS with remote SSH

[KireinaHoro]

Describe the bug

I'm trying to import a Mill-based project through remote SSH with Metals. Seems like the plugin locates JDK correctly and downloads all the required Maven dependencies, but couldn't start the server. Log:

Metals version: 1.3.5
Using coursier located at /Users/jsteward/.metals/cs
Searching for Java on PATH. Found java executable under /etc/profiles/per-user/jsteward/bin/java that resolves to /nix/store/hxskzr9a3m0prpy9l41bnw3rmmahvdb6-zulu-ca-jdk-21.0.2/zulu-21.jdk/Contents/Home/bin/java
    openjdk version "21.0.2" 2024-01-16 LTS
    OpenJDK Runtime Environment Zulu21.32+17-CA (build 21.0.2+13-LTS)
    OpenJDK 64-Bit Server VM Zulu21.32+17-CA (build 21.0.2+13-LTS, mixed mode, sharing)
Using Java Home: /nix/store/hxskzr9a3m0prpy9l41bnw3rmmahvdb6-zulu-ca-jdk-21.0.2/zulu-21.jdk/Contents/Home
[Error - 11:53:03] Server initialization failed.
  Message: Internal error.
  Code: -32603 
java.nio.file.FileSystemNotFoundException: Provider "vscode-remote" not installed
    at java.base/java.nio.file.Path.of(Path.java:213)
    at java.base/java.nio.file.Paths.get(Paths.java:98)
    at scala.meta.internal.mtags.MtagsEnrichments$XtensionURIMtags.toAbsolutePath(MtagsEnrichments.scala:130)
    at scala.meta.internal.mtags.MtagsEnrichments$XtensionStringMtags.toAbsolutePath(MtagsEnrichments.scala:187)
    at scala.meta.internal.metals.MetalsEnrichments$XtensionString.toAbsolutePath(MetalsEnrichments.scala:773)
    at scala.meta.internal.metals.MetalsEnrichments$XtensionString.toAbsolutePath(MetalsEnrichments.scala:770)
    at scala.meta.internal.metals.Folder$.apply(WorkspaceLspService.scala:1403)
    at scala.meta.metals.MetalsLanguageServer.$anonfun$initialize$4(MetalsLanguageServer.scala:148)
    at scala.collection.immutable.List.map(List.scala:247)
    at scala.meta.metals.MetalsLanguageServer.initialize(MetalsLanguageServer.scala:148)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
    at java.base/java.lang.reflect.Method.invoke(Method.java:580)
    at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$recursiveFindRpcMethods$0(GenericEndpoint.java:65)
    at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.request(GenericEndpoint.java:128)
    at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleRequest(RemoteEndpoint.java:271)
    at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:201)
    at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:185)
    at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:97)
    at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:114)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
    at java.base/java.lang.Thread.run(Thread.java:1583)

To Reproduce Steps to reproduce the behavior:

1. Open Mill project through remote SSH
2. Wait for Metals to start
3. Metals fail to start with a prompt "Internal error"

Expected behavior

Metals should successfully import the project

Installation:

• Operating system: macOS
• VSCode version: 1.89.1
• VSCode extension version: 1.39.0
• Metals version: (found in VSCode settings, under metals.serverVersion) 1.3.5

[tgodzik]

Looks like the path being fed to Metals starts with vscode-remote: and we have no way of working with that. Not sure what is expected of extensions in that case.

[KireinaHoro]

I just tried installing the extension on the remote host as well, and now it seems to work without problems. Maybe the extension can request itself to be installed on the remote machine, like the native CPP extension does?

[tgodzik]

Curiously, Metals defines itself as a workspace extension first, which should force VS Code to run it on the same machine as the workspace. We could remove the second ui part as most likely that will not be possible to do.