Debugger crashes with Scala/Metals: invalid value: integer `-1`, expected u64

[anjunar]

Summary

When trying to debug a minimal Scala 3 project in Zed using the Scala/Metals extension, the debugger fails with:

invalid value: integer -1, expected u64

The project itself compiles and runs successfully via sbt run, so this appears to be an issue in Zed's DAP client deserialization rather than in the Scala code or sbt setup.

This looks similar to previous JVM/DAP issues where a debug adapter sends -1 for a field such as a stack frame line number when no source location is available, while Zed expects an unsigned integer (u64).

---

Environment

OS: Windows
Zed version: <please fill in>
Scala extension version: <please fill in>
Scala version: 3.3.5
sbt version: 1.12.11
JDK: Java 21
Metals version: <please fill in if known>

---

Minimal reproduction project

build.sbt

ThisBuild / scalaVersion := "3.3.5"

lazy val root = (project in file("."))
  .settings(
    name := "test",
    Compile / mainClass := Some("com.anjunar.Main")
  )

src/main/scala/com/anjunar/Main.scala

package com.anjunar

object Main {

  def main(args: Array[String]): Unit = {
    println("Hello World!")
    println("Hello World!")
    println("Hello World!")
  }

}

.zed/debug.json

[
  {
    "label": "Debug Scala Main (Metals launch)",
    "adapter": "Metals",
    "request": "launch",
    "mainClass": "com.anjunar.Main",
    "args": [],
    "jvmOptions": [],
    "env": {}
  }
]

---

Steps to reproduce

1. Open the minimal Scala project in Zed.

2. Make sure the Scala/Metals extension is installed and Metals has imported the sbt build.

3. Add a breakpoint in Main.scala, for example on one of the println lines.

4. Start the debug configuration:

   Debug Scala Main (Metals launch)
   

5. The debugger fails with:

   invalid value: integer `-1`, expected u64
   

---

Expected behavior

Zed should start the debug session successfully, stop at the breakpoint, and display stack frames / variables.

If the debug adapter sends -1 for a field like a stack frame line number where no source location exists, Zed should either accept it or normalize/ignore it instead of failing the whole debug session.

---

Actual behavior

The debug session fails with:

invalid value: integer `-1`, expected u64

---

Additional notes

The project itself runs fine outside the debugger:

sbt run

Output:

Hello World!
Hello World!
Hello World!

So the issue seems specific to the Zed debugger / DAP deserialization path.

This may be related to JVM debug adapters sending -1 for source-less stack frames. Previous similar reports mention StackFrame.line or similar DAP fields being deserialized as u64 even though the adapter may return -1.

A more robust behavior would be to tolerate -1 from JVM debug adapters, or map it to 0 / None for fields where missing source locations are expected.

[susuro]

This is caused by scalacenter/java-debug#12 and is waiting for the upstream merge

[tgodzik]

I don't how but I missed that fix 😓 It's merged now, we will need to also update the submodule in the scala-debug-adapter. I don't remember the workflow exactly, will check.

[tgodzik]

I updated scala-debug-adapter and released the changes. They will be avialable in the next metals version