Multiple `executionContext/create` messages prevent app startup

[hubertp]

Discord username

No response

What type of issue is this?

Permanent – Occurring repeatably

Is this issue blocking you from using Enso?

• [X] Yes, I can't use Enso because of this issue.

Is this a regression?

• [X] Yes, previous version of Enso did not have this issue.

What issue are you facing?

Somewhere between 08/05 and 17/05 a regression was introduced that leads to multiple executionContext/create requests being sent by GUI when creating a new project (likely also when opening an existing project).

See screenshot.

Expected behaviour

No failures on startup on a hello world example.

How we can reproduce it?

Try to open a new project with latest nightly.

Screenshots or screencasts

Logs

error: 
{code: 2004, message: "Invalid stack item"}

Enso Version

17/05 nightly

Browser or standalone distribution

Standalone distribution (local project)

Browser Version or standalone distribution

standalone

Operating System

Linux

Operating System Version

No response

Hardware you are using

No response

[hubertp]

I don't see any issues in nightly from 14/05 (no nightiles between 14th and 17th, so can't triage that one easily).

[hubertp]

It appears to be only(?) reproducible for less powerful machines. Still, I think we should discuss retries that GUI is making as some of the sent messages are not idempotent.

[farmaazon]

It appears to be only(?) reproducible for less powerful machines. Still, I think we should discuss retries that GUI is making as some of the sent messages are not idempotent.

I'm aware of the problem with retries, but honestly I haven't expected we hit it so early :)

Technically, on problems like "timeout" we have no idea what is the engine's state. One solution would be marking the execution context as "broken" and try to destroy it and recreate on every single failure in its creation or frame change. Perhaps visualization as well? To avoid unnecessary visualizations nobody listens to. Here the problem is, that even slight connectivity issue would destroy all caches.

So better solution would be to have an ability to read the current engine's state. Then, after a timeout, we could read the state first to check if last call was actually applied or not. But that requires adding new methods to engine.

[hubertp]

Are you sure something wasn't broken recently? I built my own nightlies and narrowed it down to somewhere between 14th and 15th, i.e. 52b8ed4d3a01711a70ef65c1f53d9a33adbe0509...c437721ba5623e6d167ea040832be08b2d84dbe7.

[hubertp]

I'm afraid I narrowed it down to your commit, @vitvakatu, 52b8ed4d3a01711a70ef65c1f53d9a33adbe0509. It's weird though, it looks innocent. To verify you can build IDE with 43c80da8a313f48bc7b492f37cc9c651cf7dea71 and 52b8ed4d3a01711a70ef65c1f53d9a33adbe0509 with a fixed nightly backend. The former will be fine with a simple Hello World project, the latter not.

[farmaazon]

Let's also see if it gets fixed by #9951 as it fixes the same project being initialized twice.

[hubertp]

Still seeing the problem. It's actually a combination of multiple executionContext/create and executionContext/push.

[hubertp]

This issue should be visible once the other PR gets merged.

[hubertp]

@farmaazon noticed a similar issue when trying it out with electron app and connecting to cloud:

EDIT: changed my mind. Those are similar issues but not exactly the same. Filed https://github.com/enso-org/enso/issues/10495. This is reproducible when connecting to cloud project via electron app.