Katarzyna Marek

Hi, I'm not really able to reproduce the issue just by having `scala` and `java` share package and reference each other. Do you have a small reproduction of the problem?...

Thanks for the report. I can reproduce that. It's not a metals issue, we only send requests to the build server to compile a specific build target. I can reproduce...

Closing this as resolved by: https://github.com/scala/scala3/pull/19911

The issue seems to be the bsp config generated by `sbt` (`.bsp/sbt.json`). The args for starting the server are: ``` [some-path]/java -Xms100m -Xmx100m -classpath [some-path]/sbt-launch.jar -Dsbt.script=[some-path]/sbt xsbt.boot.Boot -bsp ``` Which...

@untainsYD did setting sbt script in metals settings actually solved the issue for you?

I don't think it will work right now. So it seems that starting `sbt` server using`.../java ... xsbt.boot.Boot -bsp` causes `.sbt` to be created (one would have to pass `Dsbt.boot.directory=`...

This is something we could show in the metals doctor, the java version that is in `.bloop/bloop.json`. If things get out of sync it will at least be visible.

It seems there are two issues here: 1. we depend on go to references (semanticdb) to find the files which need importing fixes, so if the files don't compile/build target...

The second case seems to still be an issue sometimes when using `bloop`. There must be some race condition there. `bloop` gets stuck and sees the previous (before change) symbol...

> I mean the steps 4-5 happen without test involvement. I think this too might be a `bloop` error connected to deduplicating compilations.