Describe the bug
Process Framework has parent-less Edges which difficult rendering the Process Graph (and will difficult proper design tooling)
Usually a Step (node) has edges to other Steps which is OK.
But, in case of a Step which is a Process (ie, composed of other steps), This Step can have an Edge to an Inner Step, which makes no sense. After a great discussion with the team, @alliscode and @esttenorio (thanks a ton for the great interaction and discussion) this is done at the moment to represent Entry Steps, where the workflow is starting on the Process Step.
This made it impossible to draw this properly and is ignored, but upon discovery it was rendered like this for reference:
And if we debug the Edges of the Step which is a Process, we see it has two, the second one properly formed is the exit Edge but the first one on the Edge Key it does not have a properly formed EventId but a simple name:
This comes from the entry point defined next (Thanks @esttenorio for finding it):
Here is there the root process steps "links" with the internal steps of the nested process.
Which works, but we end up with a Edge from an "event" (FriedFishProcess.ProcessEvents.PrepareFriedFish) to an Internal Step.
The biggest problem here is that the Event is parentless, not associated to a Step. So, we cannot "paint" the graph to depict where does it come from.
The technical solution is to attach the Edge to the target Step, but it has no parent.
Proposal: Make all Events with a Single Parent. One Event, One Parent, point. And associate the events to that parent through an Edge. so we know where it starts and where it ends(goes). This way will enable proper tooling and accurate rendering - and the inherent graph will not try to "trick us".
Go to ProcessVisualizationExtensions, line 104 in the Process.Core project and add a breakpoint.
Debug test UsePrepareFishSandwichProcessAsync
Review the Edges once it goes out of the Step which is a KernelProcess, after rendering it it will go to render the Edges and then one of the Edges will be ignored due to not having a "step father" - it comes from an event so just a name is in there, so cannot be "related", rendered or tooled around. You will see something similar to this:
Expected behavior
I want all edges to happily have a father so I can draw them on the Graph and in a future, have a tool that can draw them and debug them and know where they come from and where they go.
Platform
OS: Windows (does not matter, not OS related)
IDE: VS
Language: C#
Source: main
Additional context
Add any other context about the problem here.
Describe the bug Process Framework has parent-less Edges which difficult rendering the Process Graph (and will difficult proper design tooling)
Usually a Step (node) has edges to other Steps which is OK. But, in case of a Step which is a Process (ie, composed of other steps), This Step can have an Edge to an Inner Step, which makes no sense. After a great discussion with the team, @alliscode and @esttenorio (thanks a ton for the great interaction and discussion) this is done at the moment to represent Entry Steps, where the workflow is starting on the Process Step.
This made it impossible to draw this properly and is ignored, but upon discovery it was rendered like this for reference:
And if we debug the Edges of the Step which is a Process, we see it has two, the second one properly formed is the exit Edge but the first one on the Edge Key it does not have a properly formed EventId but a simple name:
This comes from the entry point defined next (Thanks @esttenorio for finding it):
Here is there the root process steps "links" with the internal steps of the nested process.
Which works, but we end up with a Edge from an "event" (FriedFishProcess.ProcessEvents.PrepareFriedFish) to an Internal Step. The biggest problem here is that the Event is parentless, not associated to a Step. So, we cannot "paint" the graph to depict where does it come from. The technical solution is to attach the Edge to the target Step, but it has no parent.
Proposal: Make all Events with a Single Parent. One Event, One Parent, point. And associate the events to that parent through an Edge. so we know where it starts and where it ends(goes). This way will enable proper tooling and accurate rendering - and the inherent graph will not try to "trick us".
To Reproduce Steps to reproduce the behavior: Once my PR https://github.com/microsoft/semantic-kernel/pull/9705 is merged :)
Expected behavior I want all edges to happily have a father so I can draw them on the Graph and in a future, have a tool that can draw them and debug them and know where they come from and where they go.
Platform
Additional context Add any other context about the problem here.