Read only mode in IDE

[vitvakatu]

Hi! We want to discuss the details for the read-only mode that would be enabled after clicking on the Workflow-level Play button (see design doc).

Questions for the Engine team (@JaroslavTulach @hubertp @4e6 )

1. Is opening visualizations (attach them) safe during execution? Should we disallow opening visualizations for the user?
2. What about visualizations already opened when pressing the Play button? Should we allow them to close? Do we need to close them all forcefully to avoid negative effects on the execution?
3. Do we need to disallow moving nodes in read-only mode? Moving nodes will update the project's metadata, which would cause the engine to consider it a code edit. Therefore we should forbid moving nodes. Is it correct?

[4e6]

1,2 Attaching or detaching visualizations does not interrupt the running program. Attaching may cause program re-execution if the visualized value was not cached.
3. All source code changes including changes in the metadata can lead to interruption of the running program and its re-execution. To prevent the interruption and re-execution, the text edit should be sent with execute: false flag https://github.com/enso-org/enso/blob/310a2d8ae753f31e6784d512776465706306f56c/docs/language-server/protocol-language-server.md#textapplyedit

[4e6]

I believe, in the scenario described by @jdunkerley the interruption of running computation happened because of the node movements. Node movements produce text edits (editing the metadata) and cause the engine to interrupt and re-execute the program after applying the edits. This can be fixed by adding execute: false flag to text edit messages.

Visualization attachment may only cause program execution (without interrupting the currently running one). If we want to prevent the program execution as well, we can add, for example, execute: false flag to the executionContext/attachVisualization command that will prevent the program execution after attaching the visualization.

[JaroslavTulach]

This can be fixed by adding execute: false flag to text edit messages

OK, so the IDE has full control on whether an edit is going to lead to re-execution or not. I believe that allows the IDE to send only safe edits that are not going to cause re-execution.

Visualization attachment may only cause program execution (without interrupting the currently running one)

I believe that additional execution is fine (at least from today's perspective). Let the IDE send executionContext/attachVisualization commands for now. Should it cause some problems in the future, we can investigate and decide the best mitigation.

[farmaazon]

Should it cause some problems in the future, we can investigate and decide the best mitigation.

As I wrote, I see a clear problem it may cause: e.g. create doubled database transactions when we run new execution in production mode (or whatever name we currently use for "execution with side effects").

[hubertp]

As I wrote, I see a clear problem it may cause: e.g. create doubled database transactions when we run new execution in production mode (or whatever name we currently use for "execution with side effects").

But changing the execution environment (from live to design or the other way around) will cancel all pending executions, before re-running things.

[vitvakatu]

But changing the execution environment (from live to design or the other way around) will cancel all pending executions, before re-running things.

We're talking about visualizations attachment, and it can cause double execution, according to @4e6