Running tests from Emacs stopped working

[chessman]

Describe the bug

I can still run tests using bloop but in Emacs dap-mode it doesn't work anymore. I see a suspicious UncheckedIOException in metals logs - I do have /home directory.

Also, is it ok that the client in traces is shown as "vscode"?

2022.01.31 15:37:28 INFO  tracing is enabled: /home/ea/src/modulus-executors/.metals/dap-server.trace.json
2022.01.31 15:37:28 INFO  tracing is enabled: /home/ea/src/modulus-executors/.metals/dap-client.trace.json
2022.01.31 15:37:28 INFO  Starting debug proxy for [<...edited...>]
Jan 31, 2022 3:37:30 PM org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer fireStreamClosed
INFO: Connection reset
java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(SocketInputStream.java:210)
    at java.net.SocketInputStream.read(SocketInputStream.java:141)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
    at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:79)
    at scala.meta.internal.metals.debug.SocketEndpoint.listen(SocketEndpoint.scala:26)
    at scala.meta.internal.metals.debug.MessageIdAdapter.listen(MessageIdAdapter.scala:47)
    at scala.meta.internal.metals.debug.ServerAdapter.onReceived(ServerAdapter.scala:18)
    at scala.meta.internal.metals.debug.DebugProxy.$anonfun$listenToServer$1(DebugProxy.scala:67)
    at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
    at scala.concurrent.Future$.$anonfun$apply$1(Future.scala:659)
    at scala.util.Success.$anonfun$map$1(Try.scala:255)
    at scala.util.Success.map(Try.scala:213)
    at scala.concurrent.Future.$anonfun$map$1(Future.scala:292)
    at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:33)
    at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)
    at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

2022.01.31 15:37:30 INFO  Canceling debug proxy for [<...edited...>]
2022.01.31 15:37:30 ERROR java.io.UncheckedIOException: java.nio.file.NoSuchFileException: /home
2022.01.31 15:37:30 INFO  Closing debug server tcp://0.0.0.0:39405

dap-server.trace.json

[Trace][03:37:28 PM] Sent request:
{
  "type": "request",
  "seq": 1,
  "command": "initialize",
  "arguments": {
    "clientID": "vscode",
    "clientName": "Visual Studio Code",
    "adapterID": "scala",
    "pathFormat": "path",
    "linesStartAt1": true,
    "columnsStartAt1": true,
    "supportsVariableType": true,
    "supportsVariablePaging": true,
    "supportsRunInTerminalRequest": true,
    "locale": "en-us"
  }
}

dap-client.trace.json

[Trace][03:37:28 PM] Received request:
{
  "type": "request",
  "seq": 1,
  "command": "initialize",
  "arguments": {
    "clientID": "vscode",
    "clientName": "Visual Studio Code",
    "adapterID": "scala",
    "pathFormat": "path",
    "linesStartAt1": true,
    "columnsStartAt1": true,
    "supportsVariableType": true,
    "supportsVariablePaging": true,
    "supportsRunInTerminalRequest": true,
    "locale": "en-us"
  }
}

Expected behavior

No response

Operating system

Linux

Editor/Extension

Emacs (lsp-metals)

Version of Metals

v0.11.1

Extra context or search terms

No response

[tgodzik]

Thanks for reporting! "clientName": "Visual Studio Code", seems suspicious, but that is set (or should be) by the dap-mode. What is your java home? Looks like it's an issue with the debugging process not able to start. Does it work for you on an earlier Bloop version?

@kpodsiad do you think this could have been caused by your recent changes?

[chessman]

@tgodzik Yep, looked in dap-mode code, it pretends to be vscode. Checked metals with different bloops: 1.4.12, 1.4.11, 1.4.10, got the same error in metals.log. bloop test works on all versions. Actually, I installed very old Metals 0.10.0 (cs install metals:0.10.0) and also had the same problem. It is weird, because it definitely worked before. JAVA_HOME is /home/ea/.cache/coursier/jvm/amazon-corretto@1.8.292-10.1.

[kpodsiad]

@kpodsiad do you think this could have been caused by your recent changes?

I don't think so, especially because I haven't touched dunning internals yet. If metals:0.10.0 doesn't work either something else has to be an issue (however, I'll have a closer look at this tomorrow just to be sure).

@tpasternak are you able to run tests on your machine?

[tgodzik]

Actually, this doesn't seem to be related to Emacs at all, but to the broken swagger jar reported in https://github.com/scalameta/metals/issues/3594

@chessman is it the same workspace? I cannot run/debug either and it seem the fault is in unhandled exception in https://github.com/scalacenter/scala-debug-adapter

[chessman]

@tgodzik Yes, this is the same project containing the broken jar.

[tgodzik]

@tgodzik Yes, this is the same project containing the broken jar.

Cool, that should be fixed by the other PR

https://github.com/scalacenter/scala-debug-adapter/pull/186

[chessman]

I can confirm that it works with Metals 0.11.2. Thanks for the fix!