Visualizations are getting blank when uploading a file to the workflow

[sylwiabr]

Discord username

No response

What type of issue is this?

Permanent – Ocurring repeatably

Is this issue blocking you from using Enso?

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

Is this a regression?

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

What issue are you facing?

When uploading a file the visualizations on already existing nodes are getting blank. Please, see the video.

Expected behaviour

Existing open visualizations should not blink (update), and definitely should not go blank.

How we can reproduce it?

No response

Screenshots or screencasts

Nagranie.z.ekranu.2023-03-17.o.14.51.48.mov

Enso Version

126a466

Browser or standalone distribution

Standalone distribution

Browser Version or standalone distribution

Standalone

Operating System

MacOS

Operating System Version

No response

Hardware you are using

No response

[vitvakatu]

Can reproduce, bisecting now.

[vitvakatu]

The issue seems to be caused by commit 7a40ccc3ea02321a6e699c0d4cd2bb187f5d9de2 (#5906)
Assigning to @MichaelMauderer
cc @farmaazon

[wdanilo]

The issue seems to be caused by commit 7a40ccc3ea02321a6e699c0d4cd2bb187f5d9de2 (#5906)
Assigning to @MichaelMauderer
cc @farmaazon

I'm wondering how on earth that PR could influence it. Seems not connected at all to me and seems like a random ordering issue. I might be wrong though.

[MichaelMauderer]

Maybe some layout recalculation issue? This PR introduces a new use of client_x/client_y. That could then lead to some unspecified orderings to change.

[wdanilo]

Oh, so do you think this is related to HTML dom elements ordering? Might be! But this is wild. When you'd know what it is, please tell me, as I'm dying out of curiosity!

[enso-bot]

Michael Mauderer reports a new STANDUP for today (2023-03-29):

Progress: Opened PR for execution mode dropdown. Started investigating the blinking of visualization when dropping files. It should be finished by 2023-03-31.

Next Day: Next day I will be working on the #5991 task. Continue investigation into the root cause.

[enso-bot]

Michael Mauderer reports a new STANDUP for today (2023-03-30):

Progress: Had some initial trouble reproducing the issue, but found a reliable reproduction now. But I also found that the issue is not caused by the PR that lead to this being detected, it can be reproduced without the changes from that PR if enough visualizations are open. This could mean that there is some timing issue going on. It should be finished by 2023-03-31.

Next Day: Next day I will be working on the #5991 task. Continue investigation into the root cause.

[enso-bot]

Michael Mauderer reports a new STANDUP for today (2023-03-31):

Progress: Not as much progress here as I had hopes as I keep running into random build failures, requiring full rebuilds, which is taking a lot of time. I added some more logging to figure out the chain of events leading to the vanishing visualizations, but no definitive root cause identified yet. It should be finished by 2023-03-31.

Next Day: Next day I will be working on the #5991 task. Continue investigation into the root cause.

[MichaelMauderer]

We are putting this on hold for the moment to prioritize other tasks. Some notes from the current investigation:

How to reliably reproduce:

• Create a new node with a table visualization.
• Make sure at least two table visualizations are open/visible in the window (at least one of them on the node that was created in this session).
• Drop a file into the scene to create a new node.
  Result:
• The visualization(s) on the nodes that were created in this session will be blank.
• The following error will be in the debug log (different IDs of course)

index.js:10 [ERROR] app/gui/src/model/execution_context/plain.rs:246 Failed to dispatch update to visualization c1a53e84-0329-499b-bac8-8d6f5b1d9864. Failed to found such visualization.

index.js:10 [ERROR] app/gui/src/model/project/synchronized.rs:417 Failed to handle the visualization update: Tried to use incorrect visualization Id: c1a53e84-0329-499b-bac8-8d6f5b1d9864.

This above reproduction can be stopped from happening by removing the calls to client_x/client_y in lib/rust/ensogl/component/drop-manager/src/lib.rs:181, but this is not the root cause.

The error can also sometimes happen when removing a node, as opposed to dropping one.

When removing the calls to client_x/client_y in the above location, the bug can still be reproduced if a large number of visualizations is open. More than 10 on my machine reliable reproduce the issue.

Next steps:

• Investigate the error message.
• Investigate the handling of visualization IDs.
• Investigate the message passed between engine<->controller<->visualizations.

[sylwiabr]

Can not reproduce after fixes from @farmaazon