FileAlreadyExistsException when compiling bridges

[tgodzik]

This popped up in out tests and might be a reason for making things flaky on our side, however I am not entirely sure.

This does look like a bug though, but might happen very rarely when compiling bridges get invoked twice via BSP (that's my guess)

2023.10.02 09:23:24 INFO  time: indexed workspace in 3.53s
2023.10.02 09:23:26 INFO  BSP server: Compiling compiler interface...
2023.10.02 09:23:37 INFO  BSP server: [info] compiling 1 Scala source to /home/runner/work/metals/metals/tests/slow/target/e2e/mill-server-lenses/run-mill-lens/out/MillMinimal/compile.dest/classes ...
2023.10.02 09:23:39 INFO  BSP server: [info] done compiling
2023.10.02 09:23:39 INFO  BSP server: [info] compiling 1 Scala source to /home/runner/work/metals/metals/tests/slow/target/e2e/mill-server-lenses/run-mill-lens/out/MillMinimal/test/compile.dest/classes ...
2023.10.02 09:23:39 INFO  BSP server: [info] done compiling
2023.10.02 09:23:40 INFO  BSP server: Compiling compiler interface...
2023.10.02 09:23:50 INFO  compiling target millminimal
2023.10.02 09:23:50 INFO  BSP server: Caused by: java.lang.Exception: Failure during task evaluation: MillMinimal.compile java.nio.file.FileAlreadyExistsException: /home/runner/work/metals/metals/tests/slow/target/e2e/mill-server-lenses/run-mill-lens/out/mill/scalalib/ZincWorkerModule/worker.dest/zinc-1.9.5/2.13.12/compiled/DONE
2023.10.02 09:23:50 INFO  BSP server:     java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:94)
2023.10.02 09:23:50 INFO  BSP server:     java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
2023.10.02 09:23:50 INFO  BSP server:     java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
2023.10.02 09:23:50 INFO  BSP server:     java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:218)
2023.10.02 09:23:50 INFO  BSP server:     java.base/java.nio.file.Files.newByteChannel(Files.java:380)
2023.10.02 09:23:50 INFO  BSP server:     os.write$.write(ReadWriteOps.scala:64)
2023.10.02 09:23:50 INFO  BSP server:     os.write$.apply(ReadWriteOps.scala:77)
2023.10.02 09:23:50 INFO  BSP server:     mill.scalalib.worker.ZincWorkerImpl.compileBridgeIfNeeded(ZincWorkerImpl.scala:268)
2023.10.02 09:23:50 INFO  BSP server:     mill.scalalib.worker.ZincWorkerImpl.withCompilers(ZincWorkerImpl.scala:387)
2023.10.02 09:23:50 INFO  BSP server:     mill.scalalib.worker.ZincWorkerImpl.compileMixed(ZincWorkerImpl.scala:331)
2023.10.02 09:23:50 INFO  BSP server:     mill.scalalib.ScalaModule.$anonfun$compile$2(ScalaModule.scala:212)
2023.10.02 09:23:50 INFO  BSP server:     mill.define.Task$TraverseCtx.evaluate(Task.scala:71)
2023.10.02 09:23:50 INFO  BSP server: 	at mill.eval.Evaluator.$anonfun$evalOrThrow$default$1$1(Evaluator.scala:42)
2023.10.02 09:23:50 INFO  BSP server: 	at mill.eval.EvaluatorImpl$EvalOrThrow.apply(EvaluatorImpl.scala:66)
2023.10.02 09:23:50 INFO  BSP server: 	at mill.bsp.worker.MillBuildServer.$anonfun$completableTasks$5(MillBuildServer.scala:648)
2023.10.02 09:23:50 INFO  BSP server: 	at scala.collection.StrictOptimizedIterableOps.map(StrictOptimizedIterableOps.scala:100)
2023.10.02 09:23:50 INFO  BSP server: 	at scala.collection.StrictOptimizedIterableOps.map$(StrictOptimizedIterableOps.scala:87)
2023.10.02 09:23:50 INFO  BSP server: 	at scala.collection.immutable.Map$Map3.map(Map.scala:389)
2023.10.02 09:23:50 INFO  BSP server: 	at mill.bsp.worker.MillBuildServer.$anonfun$completableTasks$1(MillBuildServer.scala:647)
2023.10.02 09:23:50 INFO  BSP server: 	at mill.bsp.worker.MillBuildServer.$anonfun$completable$1(MillBuildServer.scala:684)
2023.10.02 09:23:50 INFO  BSP server: 	... 8 more
2023.10.02 09:23:50 INFO  BSP server: 

[lefou]

@tgodzik Thanks for bringing this to our attention. Looks like BSP (now) sends request in parallel. Has this changed or was it always this way? I've never seen those concurrency issues last year. Nevertheless, I think Mill is handling BSP requests in a racy way, so we have some homework. Maybe, we should just limit the executor, that handles the incoming requests to one, for now?

• Related discussion: task evaluation concurrency #2820

[lefou]

This issue is fixed by #2980

[tgodzik]

Thanks!