Moving class to other folder generates import errors in other project

[brndt]

Describe the bug

Reproduction steps:

1. Move class to other folder (in my case I move CreatePlayer* classes located in service folder to its subfolder create)
2. All import changes in root project are working fine although in log you can find: 2023.10.17 18:39:23 ERROR Build server error: Unexpected error when compiling root: '/Users/***/projects/zio-console/src/main/scala/com/spursarmy/app/player/domain/service/CreatePlayer.scala (No such file or directory)'
3. Import changes in test project are not made and errors are shown
4. Activate and set 'auto save' to 'afterDelay' and repeat 1-2 steps.
5. Import changes in test project are made and errors are shown although in this case they're falsy saying that the imported classes are not found by new package path 5.1. if you click 'clean compile' the errors disappear

PS: When you have the option 'auto save' set to 'false' (step 1) errors are not always generated and everything works fine meanwhile with 'afterDelay' (4-5-6 steps) falsy errors are always shown.

Expected behavior

No response

Operating system

macOS

Editor/Extension

VS Code

Version of Metals

v1.1.0

Extra context or search terms

No response

[tgodzik]

Thanks for the report! We should be able to take a look at this and figure out what is going on.

[kasiaMarek]

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 wasn't yet compiled it changing import names may not work as it should (I didn't see it failing to fix imports in a different scenarios),
2. metals sends the changes to vscode and stored in the buffer, with 'auto save' set to 'afterDelay' the files are automatically saved in an order we don't have control over. Since we compile only the build target with the saved file, we might compile first test only then main, even if the test file is open. Solution: recompile also the build target in focus if it is an inverse dependency of the currently compiled build target (https://github.com/scalameta/metals/pull/5785).

[kasiaMarek]

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 instead of the new one in test, recompiling test (without a new change or with a new change) nor main (without a new change) doesn't change anything. Only making a change in main and recompiling gets it unstuck.

[brndt]

It's something that also happens to me within main. If I move some file to other folder, other classes seems to detect the package change and have the correct import but VS Code tells that imported stuff is not found by package reference. I mean the steps 4-5 happen without test involvement.

[kasiaMarek]

I mean the steps 4-5 happen without test involvement.

I think this too might be a bloop error connected to deduplicating compilations.