An entry with the same key already exists exception in visualizer mapping and groups

[glopesdev]

Visualizer and workflow input/output propagations seem to have a number of elusive issues in the latest language release. Some examples of reported behaviors to investigate:

• Multiple VisualizerMapping inputs to the same node, and modifying the type of one of the input sequences can sometimes trigger this exception
• Grouping sub-workflows with multiple input sequences will also sometimes create this exception (hard to reproduce), even though creating the group by hand will not

[glopesdev]

Still unclear on how to predictably reproduce this, most likely this comes from one of two possible sources:

ResetVisualizerMappings not called

bonsai/Bonsai.Core/Expressions/InspectBuilder.cs

Line 39 in d3317bb

internal void AddVisualizerMapping(int index, InspectBuilder source, Type visualizerType)

This method can throw if duplicate entries are added. It is automatically cleared on build by a call to ResetVisualizerMappings inside InspectBuilder.

There is however a risk that throwing of exceptions might prevent this. In theory this case should be handled by the call to ResetVisualizerMappings inside the catch clause below:

bonsai/Bonsai.Core/Expressions/ExpressionBuilderGraphExtensions.cs

Line 686 in d3317bb

builder.ResetVisualizerMappings();

However, perhaps there is some other tortuous code path whereby the cache might not be cleared.

Duplicate edge labels

Duplicate key exceptions might also be raised if the same edge is added twice into the visualizer mapping. This should never happen under normal conditions, and we have debugged this extensively, but there might still be graph manipulation sequences that generate inconsistent labeling.

I find this option less likely since if it were the culprit it should affect other node types, as duplicate keys will crash any node build. There should be no reason why only VisualizerMapping nodes are affected in this case, unless of course there is some tortuous graph manipulation sequence in the editor that only happens specifically when manipulating visualizer mapping nodes.

[PathogenDavid]

Duplicate edge labels

(Edit: I remember why I didn't say something about this sooner. I think I decided I wasn't confident that I wasn't just accidentally trying to modify the graph while it was running. Leaving this comment in case it makes you think of something though.)

Something I almost forgot about from when I was trying to repro this on Friday: I was occasionally ending up in weird scenarios where I couldn't add or remove certain edges anymore. It'd come and go seemingly at random so I never got a repro. (I swear at one point I got up to let Nova out and when I came back it was working again.)

Is there maybe duplicated state related to graph edges that are getting out of sync somehow? (Which maybe sometimes manifests its self as my weirdness and other times manifests as this crash?)

Edit 2: I think I just accidentally re-discovered what was happening on Friday. When I press control instead of shift to remove edges, it does something weird. I don't think there's actually meant to be functionality tied to pressing control and dragging between two nodes, so there might be something to investigate further there.

[RoboDoig]

I don't think there's actually meant to be functionality tied to pressing control and dragging between two nodes, so there might be something to investigate further there.

I thought this functionality was for swapping node order in a branch? Do you have an example of where it has weird behaviour?

[PathogenDavid]

I thought this functionality was for swapping node order in a branch?

I believe that's alt:

bonsai/Bonsai.Editor/GraphView/WorkflowGraphView.cs

Lines 1391 to 1395 in 08512e1

	private void reconnectToolStripMenuItem_Click(object sender, EventArgs e)
	{
	InitializeConnectionSource();
	dragKeyState = AltModifier;
	}

Do you have an example of where it has weird behaviour?

Yes and no.

While reverse engineering what sleep-deprived David was doing last Friday, I finally noticed what I was occasionally doing: If you have multiple nodes selected, you can't delete edges with shift anymore. Maybe that could be improved, but it's also slightly a case of me holding it wrong. Part of what made it confusing is that undoing doesn't restore the node selection state, so things would "magically" begin working again when I did undo+redo etc.

As for the confusing behavior with control, start with this workflow:

While holding control, drag from Grayscale to either node.

Dragging to camera capture results in:

Dragging to concat results in:

Maybe this is doing something sensible and useful, but I'm not sure what. This might be partially a case of betrayed expectations since I was expecting a connection to be removed, but the wrong connection was removed in the first case and in the second case it just ???.

[glopesdev]

While holding control, drag from Grayscale to either node.

Ah, this is actually a function of the Ctrl modifier, which moves the node to become a direct successor of the target node (inline), rearranging the workflow as necessary. The mouse icon should also change to a cross-hair to reflect this.

This function was introduced a few years ago to try and make it easier to rearrange bits and pieces of the workflow visually without having to delete and redo edges when you just want to move something to a specific place. It remains a cryptic action though and not widely used, so we can review it in the future.

[PathogenDavid]

Ah yeah I can see that now, thanks for clarifying!