Bloop returns wrong errors

[ColOfAbRiX]

Bloop returns wrong errors, as in code is correct and sbt compiles but bloop is not happy. See scalameta/metals#8520

This problem has been impacting me a lot, metals becomes unreliable, metals mcp doesn't work and AI cannot use it.

I tested this issue with various components:

• scala 3.8.4
• sbt 1.12.12, 2.0.x
• metals 1.6.x, 2.0.0-M16
• bloop 2.0.19, 2.1.1
• Windows 11

Reproduction

build.sbt

ThisBuild / version := "0.1.0"
ThisBuild / scalaVersion := "3.8.4"

lazy val root = (project in file("."))
  .aggregate(models, api)

lazy val models = (project in file("models"))
  .settings(name := "models")

lazy val api = (project in file("api"))
  .dependsOn(models)
  .settings(
    name := "api",
    libraryDependencies ++= Seq(
      "com.softwaremill.sttp.tapir" %% "tapir-json-circe" % "1.13.9",
      "io.circe"                    %% "circe-core"       % "0.14.16",
      "io.circe"                    %% "circe-generic"    % "0.14.16"
    )
  )

models\src\main\scala\repro\Models.scala

package repro

enum Heights:
  case High
  case Normal
  case Low
  case Other(value: String)

final case class Request(
  name: String,
  landingType: Heights
)

api\src\main\scala\repro\Endpoints.scala

package repro

import sttp.tapir.*
import sttp.tapir.generic.auto.*
import sttp.tapir.json.circe.*
import io.circe.generic.auto.*

object Endpoints:
  val allEndpoints =
    endpoint
      .post
      .in("add")
      .in(jsonBody[Request])

Then in the project root:

• sbt bloopInstall
• bloop exit (to make sure any config is reloaded)
• bloop clean (to make sure no stale data)
• bloop compile
• sbt compile

Result

> bloop compile
Compiling api (3 Scala sources)
[E] [E1] api\src\main\scala\repro\Endpoints.scala:13:28
[E]      Ambiguous given instances: both given instance derivedStringBasedUnionEnumeration in trait SchemaCompanionMacros and method derivedSchema in trait LowPrioritySchema match type sttp.tapir.Schema[repro.Request] of a context parameter of method jsonBody in trait TapirJsonCirce
[E]      L13:       .in(jsonBody[Request])
[E]                                      ^
[E] api\src\main\scala\repro\Endpoints.scala: L13 [E1]
Compiled api (1098ms)
[E] Failed to compile 'api-test', 'root-test' and 2 more projects

Using sbt:

> sbt compile
[info] welcome to sbt 1.10.0 (Microsoft Java 25.0.3)
...
[info] Executing in batch mode. For better performance use sbt's shell
[info] compiling 3 Scala sources to C:\Users\Fabrizio\projects\metals-tapir-minimal-repro\models\target\scala-3.8.4\classes ...
[info] compiling 3 Scala sources to C:\Users\Fabrizio\projects\metals-tapir-minimal-repro\api\target\scala-3.8.4\classes ...
[success] Total time: 13 s, completed 29 Jul 2026, 09:15:59

Extra info

I discovered that disabling best effort makes the issue go away:

.bloop/bloop.settings.json

{
    "javaSemanticDBVersion": "0.11.2",
    "semanticDBVersion": "4.15.2",
    "supportedScalaVersions": ["2.13.18", "2.12.21"],
    "enableBestEffortMode": false
}

I attach two files with the verbose compilation of both best effort (broken_config.log) and no best effort (working_config.log)

I checked if the issue was the scala compiler, but it doesn't look so. I used AI to create test-scalac.bat.txt wich runs directly the compiler with and without the best effort flags and compilation always succeed:

>test-scalac.bat
============================================
  Test 1: WITHOUT best-effort flags (should SUCCEED)
============================================
'out-no-betest' does not exist or is not a directory or .jar file
  scalac -help  gives more information
Exit code: 1

============================================
  Test 2: WITH best-effort flags (should also SUCCEED if compiler is fine)
============================================
'out-betest' does not exist or is not a directory or .jar file
  scalac -help  gives more information
Exit code: 1

I'll keep working to discover more info

[tgodzik]

Looks like it's a best-effort issue then, it's still experimental unfortunately. At this point I am thinking of using sourcepath instead, which seems to be much more stable solution (that's the default in Metals 2)

[ColOfAbRiX]

I am thinking of using sourcepath instead, which seems to be much more stable solution (that's the default in Metals 2)

But I started by using the defaults in Metals 2 and the issue is there. I had plenty of troubles replicating the issue and the non-issue, which I put down to caching, running servers and ai, but it might also be that I've done something wrong, I wouldn't bet my life on it

[tgodzik]

So this also happens without best-effort?

[ColOfAbRiX]

Ok, I've been working with best-effort disabled for the past day and more and I haven't had any issue so far, everything is smooth. I think I can confirm that best-effort the issue