Cycles introduce race conditions which can create unideal prototype behavior

[ellbosch]

Branch: u/ellbosch/2409/cycles-preferences

Graphs which contain cycles may present issues with expected order of operations. Our current cycles logic arbitrarily picks a node if multiple candidates are presented of equal value. In a normal DAG, this is fine—eventually values catch up to downstream nodes and so we always compute in expected order. Cycles challenge this by delaying an infinite loop's subsequent calculation for the next graph cycle. Thus, presenting scenarios where nodes may be calculated in an order not preferred by the user. An example of such a graph is represented below, where the add node needs to be evaluated before a sample and hold:

A solution was considered that presents race condition scenarios to the user, allowing them to choose preferred node starting points. This gets messy in the above graph, where there are many such race conditions that pop up, and so theoretically we'd need to support preference resolution for each unique case. This can be done but not without considerable UX brainstorming.

Furthermore, this problem exists in Origami using the same graph—without any resolution offered from their product.