Description
The SDK currently exposes a single Catch entry in GraphNodeType, however, a catch block in the DSL has two distinct visual shapes depending on its content:
- Leaf - when
catch.do is absent, the catch is a single handler with no nested flow.
- Container - when
catch.do is present, the catch wraps a sequence of child tasks that run when the error is caught, and should render as a container with its own internal subgraph.
The current single Catch type can't represent both. We need to extend GraphNodeType to add a CatchContainer variant alongside the existing leaf Catch, and route to the correct one at graph-build time based on the presence of catch.do
Motivation
- Correct visual representation - a catch with nested tasks is structurally a container (it has an internal flow), and rendering it as a leaf hides that flow from the user. They have to read the YAML to know there's anything inside.
Proposed Implementation
No response
Definition of Done
Description
The SDK currently exposes a single
Catchentry inGraphNodeType, however, a catch block in the DSL has two distinct visual shapes depending on its content:catch.dois absent, the catch is a single handler with no nested flow.catch.dois present, the catch wraps a sequence of child tasks that run when the error is caught, and should render as a container with its own internal subgraph.The current single
Catchtype can't represent both. We need to extendGraphNodeTypeto add aCatchContainervariant alongside the existing leafCatch, and route to the correct one at graph-build time based on the presence ofcatch.doMotivation
Proposed Implementation
No response
Definition of Done