Sporadic no data in visualizations on startup

[hubertp]

On startup, some nodes which have visualizations attached may show no data.
Surprisingly, when detached and attached again, data will magically re-appear.

[hubertp]

Steps to reproduce:

• setup a project with a couple of nodes
• attach visualization to a large number of nodes (~8-10)
• close the project
• open the project

I bisected GUI and found the culprit to be #11077, @kazcw.
Parent commit 3f748fd works fine, a8810e1 consistently shows "No Rows To Show" for a number of nodes. Also, I noticed a significant increase in the number of {attach,modify}Visualization requests, some of which don't really make sense to me.

[kazcw]

@hubertp, I'm not able to reproduce this with the provided "New Project 1 test standups". I have also tried enabling a larger number of visualizations, and I'm still not seeing the failure to load. I also measured {attach,modify}Visualization and did not find a difference; I'm seeing 37 attachVisualization calls and 8 modifyVisualization calls, whether testing the commit before #11077 was merged or current develop (849622e).
The steps to reproduce are also effective steps to reproduce #11121. Since that is an Undefined Behavior bug that is triggered mostly during compilation of visualization expressions, the observed behavior is consistent with this known bug. Let's re-examine this if it occurs when using a backend with #11121 fixed.

[hubertp]

I'm not the only one who has experienced this. I believe @jdunkerley has also seen those.
I'm testing with a fixed latest backend on develop (849622e) and varies only in GUI versions and I have this problem 100% consistently.
I do not believe this has anything to do with #11121 - there are 0 parser warnings/failures in the logs.
Have you tried with dev build (via browser not electron)?
Also, backend sends visualization updates correctly as I see in the logs, it is GUI which somehow ignores the data.

[hubertp]

I will do more regression testing then.
Kazam_screencast_00010.webm

[kazcw]

849622e is before the fix (#11147) was merged in 2891981. Warnings/failures are not necessarily expected due to #11121; the parser output (and thus visualization data) could simply be wrong. I would make sure this occurs after 2891981 before spending much time on it.

[hubertp]

Can't seem to reproduce the problem anymore. There have been a couple of improvements in that area, and visualizations in general should be improved (on the backend side) with #10525