Error executing EnsureCompiledJob when multiple projects are open at the same time

[somebody1234]

What type of issue is this?

Permanent – Occurring repeatably

What issue are you facing?

EnsureCompiledJob errors on the project that was opened second.

This issue occurs in #6774, not (?) on develop, because it occurs when two projects are open at the same time.

Example Error:

[error] [2023-05-25T17:06:32.511Z] [enso] Error executing org.enso.interpreter.instrument.job.EnsureCompiledJob@1df1af1
org.enso.interpreter.service.error.FailedToApplyEditsException: Some(Failed to apply edits for local.Bc_22_05.Main, edits=***, failure=InvalidPosition(Position(
38,3349), character (3349) is outside of line's length (3293)), source='***')
  at org.enso.interpreter.service.ExecutionService.lambda$modifyModuleSources$9(ExecutionService.java:384)
  at scala.util.Either.fold(Either.scala:190)
  at org.enso.interpreter.service.ExecutionService.modifyModuleSources(ExecutionService.java:381)
  at org.enso.interpreter.instrument.job.EnsureCompiledJob.applyEdits(EnsureCompiledJob.scala:251)
  at org.enso.interpreter.instrument.job.EnsureCompiledJob.ensureCompiledModule(EnsureCompiledJob.scala:84)
  at org.enso.interpreter.instrument.job.EnsureCompiledJob.$anonfun$ensureCompiledFiles$2(EnsureCompiledJob.scala:66)
  at scala.collection.immutable.List.map(List.scala:246)
  at scala.collection.immutable.List.map(List.scala:79)
  at org.enso.interpreter.instrument.job.EnsureCompiledJob.ensureCompiledFiles(EnsureCompiledJob.scala:66)
  at org.enso.interpreter.instrument.job.EnsureCompiledJob.run(EnsureCompiledJob.scala:46)
  at org.enso.interpreter.instrument.job.EnsureCompiledJob.run(EnsureCompiledJob.scala:36)
  at org.enso.interpreter.instrument.execution.JobExecutionEngine.$anonfun$runInternal$1(JobExecutionEngine.scala:111)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
  at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
  at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  at java.base/java.lang.Thread.run(Thread.java:829)
  at org.graalvm.truffle/com.oracle.truffle.polyglot.PolyglotThread.access$001(PolyglotThread.java:53)
  at org.graalvm.truffle/com.oracle.truffle.polyglot.PolyglotThread$1.execute(PolyglotThread.java:100)
  at org.graalvm.truffle/com.oracle.truffle.polyglot.PolyglotThread$ThreadSpawnRootNode.executeImpl(PolyglotThread.java:134)
  at org.graalvm.truffle/com.oracle.truffle.polyglot.PolyglotThread$ThreadSpawnRootNode.execute(PolyglotThread.java:125)
  at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.executeRootNode(OptimizedCallTarget.java:709)
  at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.profiledPERoot(OptimizedCallTarget.java:632)
  at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.callBoundary(OptimizedCallTarget.java:565)
  at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.doInvoke(OptimizedCallTarget.java:549)
  at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.callIndirect(OptimizedCallTarget.java:477)
  at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.call(OptimizedCallTarget.java:458)

Expected behaviour

No errors

How we can reproduce it?

1. Compile new Project Manager
2. Launch the IDE however you want, but with the new Project Manager (-engine.project-manager-path option)

Logs

20230525-170528-213-enso-project-manager.log

(grep for "Error executing org.enso.interpreter.instrument.job.EnsureCompiledJob", or just "EnsureCompiledJob")

Enso Version

61802b5

Browser or standalone distribution

Standalone distribution (local project)

Browser Version or standalone distribution

standalone

Operating System

Linux

[hubertp]

This is exercising a functionality in LS that in theory we were supporting but in practice we said we are abandoning - concurrent edits of a single file by multiple users. So to me it sounds like a won't fix.

[somebody1234]

@hubertp afaict though, this shouldn't be editing a single file by multiple LS instances, unless it's trying to compile stdlib files? i definitely opened two distinct projects

this is related to getting #6730 working - are there alternative ways of letting multiple LS instances run at the same time? or maybe one user running multiple instances will not be supported, only multiple users (who would maybe have different stdlib directories)?

(or have i just misunderstood the cause of the problem?)

[hubertp]

I will give that branch a try and see if I can reproduce.

[hubertp]

I'm having a hard time trying to reproduce it. Can I run

1. GUI - ./run gui watch --skip-wasm-opt in one terminal
2. BACKEND - java -jar -Dtruffle.class.path.append="runtime.jar" $JAVA_OPTS project-manager.jar --server-port 30535 -vv in a separate one (or without the hardcoded server-port)

separately to reproduce?

I opened from the dashboard two different projects and they continue to work without problems.
I tried opening the same project twice and then we have problems, as I mentioned we will.

[somebody1234]

sorry, wasn't clear - this happens when we run two separate project managers. to be fair, i'm not 100% sure whether we need to support one user running two separate project managers

[hubertp]

Sorry for the delay in getting back to you. I don't think this is an issue. We shouldn't have 2 (or more) project managers trying to manage the same project, that's bound to lead to immediate problems, as the one above.
On startup IDE will (currently) do some housekeeping when it comes to projects' metadata section, meaning it sends a bunch of edit requests. If you have two project managers and each started a separate language server to deal with requests then quickly FS contents will get out of sync when both start to receive (even the same) messages.
You can of course open different projects in separate project managers but I don't think that's what this ticket is about.

[JaroslavTulach]

FYI: CLIHandler offers a way to create a file at a well known place and use it as a lock to prevent subsequent processes to start working on the same location. In addition to that the file contains a port number with a server socket opened by the first process. That allows:

• to verify the first process is still alive
• to pass arguments to the first process and handle them there

The code is available as a Maven central library.