dataflow_visitor.go only adds further elements to the queue for ReturnValNode in the case that there’s a call stack (the first branch) if the corresponding edges have a matching index. However, a GraphNode so far only allows a single EdgeInfo for a given GraphNode as out edge.
While updateEdgeInfo aggregates information in RelPath if dest has multiple out edges, the current logic completely ignores the index of these edges. When inserting the first EdgeInfo, the provided index is used and all subsequent edges are conceptually added to the initial index.
This is problematic for the SSM Agent as we have edges with different indices.
Thus, this PR adds support for multiple EdgeInfos per GraphNode such that we can keep track of the various indices. Together with #69, the number of visited nodes by dataflow_visitor.go now seems to be deterministic for the SSM Agent codebase.
While this PR focuses on out-going edges, it remains unclear to me whether similar changes should be performed for in-coming edges.
dataflow_visitor.goonly adds further elements to the queue forReturnValNodein the case that there’s a call stack (the first branch) if the corresponding edges have a matching index. However, aGraphNodeso far only allows a single EdgeInfo for a given GraphNode as out edge. WhileupdateEdgeInfoaggregates information inRelPathifdesthas multiple out edges, the current logic completely ignores the index of these edges. When inserting the first EdgeInfo, the provided index is used and all subsequent edges are conceptually added to the initial index. This is problematic for the SSM Agent as we have edges with different indices.Thus, this PR adds support for multiple
EdgeInfos perGraphNodesuch that we can keep track of the various indices. Together with #69, the number of visited nodes bydataflow_visitor.gonow seems to be deterministic for the SSM Agent codebase.While this PR focuses on out-going edges, it remains unclear to me whether similar changes should be performed for in-coming edges.