-
|
I'm trying to better understand how declarative YAML workflow definitions get converted to a runnable Workflow entity. It appears that the WorkflowFactory and DeclarativeWorkflowBuilder classes simply inspect the YAML definition and then use a mapping to determine which concrete executor class to instantiate and add to the workflow graph. What is the purpose of the ActionHandlers? Where or when is that code used? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
Hi @pjirsa, You're reading it correctly. In the current Python runtime, declarative YAML is converted to a graph workflow via WorkflowFactory -> DeclarativeWorkflowBuilder, which maps each action kind to a concrete executor class and wires graph edges. ActionHandlers are a separate interpreter-style layer, mainly kept for non-graph compatibility and handler-focused tests; they are not the primary execution path for WorkflowFactory-built workflows. As a note: in the .NET implementation, there isn't an ActionHandler registry either: the equivalent dispatch is done by WorkflowActionVisitor, which instantiates concrete executors per action type. So for runtime behavior, the executor graph is the source of truth. I’ll file an issue to deprecate and remove the Python ActionHandler layer (and update docs/tests) so the runtime model is clearly executor-graph only. |
Beta Was this translation helpful? Give feedback.
Hi @pjirsa,
You're reading it correctly. In the current Python runtime, declarative YAML is converted to a graph workflow via WorkflowFactory -> DeclarativeWorkflowBuilder, which maps each action kind to a concrete executor class and wires graph edges.
ActionHandlers are a separate interpreter-style layer, mainly kept for non-graph compatibility and handler-focused tests; they are not the primary execution path for WorkflowFactory-built workflows. As a note: in the .NET implementation, there isn't an ActionHandler registry either: the equivalent dispatch is done by WorkflowActionVisitor, which instantiates concrete executors per action type. So for runtime behavior, the executor graph is …