Dynamically adding new nodes causes exceptions

[cwendjustus]

I've noticed adding/removing nodes/ports can cause exceptions due to race conditions. There are three cases I have documented (of which one is the Navigator Widget) but everything which makes use of the changed collections and is triggered by a re-render can cause the same exceptions to be thrown.

Note: these are lines copied from a debugging session

NavigatorWidget.cs
	foreach (... in BlazorDiagram.Nodes ...) EXCEPTION (collection was modified)
DiagramCanvas.cs
	foreach (... in BlazorDiagram.OrderedSelectables) EXCEPTION (collection was modified)
JSRuntimeExtensions.cs
	return await Microsoft.JSInterop.JSRuntimeExtensions.InvokeAsync<Rectangle>(jsRuntime, "ZBlazorDiagrams.getBoundingClientRect", new object[1] { element }); EXCEPTION (some object is null)

I think the cause is the automatic re-rendering on diagram changes while modifying collections (the nodes and/or links).
My first attempt at resolving this was setting both Diagram.SuspendRefresh and Diagram.SuspendSorting to false but this does not solve the issue.

Has anyone else experienced this issue or have suggestions?

[zHaytam]

Hello, do you maybe have a way to reproduce this consistently? That would help me fix it.

[cwendjustus]

I'm afraid I cannot provide a complete example easily. I'll give some context though.
There's a view rendering the DiagramCanvas component. When some data unrelated to the view changes, the following happens to the diagram:

• nodes and links are cleared
• new nodes are added (in a for loop, each with Nodes.Add)
• new links are created

If I'm not mistaken, these actions trigger events which cause re-rendering of the DiagramCanvas component. So the errors make sense.
I think adding a mutex for objects that can be accessed (and written to) by multiple threads at the same time would do the trick.

[cwendjustus]

The problem originates from a ReactiveUI event modifying the diagram content while it is still rendering the previous change.
Adding mutexes/locks in the code would be a mess, but adding a feature like described in #410 in the form of an event would be a nice alternative.
Although I have no clue how something like that could be easily (and consistently) implemented with all the Actions and async programming going on.

[zHaytam]

Yeah, it's tough to know exactly when the rendering finished, since a few JS calls need to be completed first.
I will try to see if I can do something about it.