Visualization & Logging
Caskada does NOT provide built-in utilities
Instead, we offer examples that you can implement yourself. This approach gives you more flexibility and control over your project's dependencies and functionality.
Understanding the execution flow of your Caskada application is crucial for debugging and optimization. The primary mechanism Caskada provides for this is the ExecutionTree returned by Flow.run().
Similar to LLM wrappers, we don't provide built-in visualization and debugging. Here, we recommend some minimal (and incomplete) implementations. These examples can serve as a starting point for your own tooling.
The ExecutionTree
ExecutionTreeWhen you execute await myFlow.run(memory), the method returns an ExecutionTree. This object provides a structured, hierarchical representation of the entire flow execution.
Structure of ExecutionTree (Conceptual):
type Action = string | 'default'
interface ExecutionTree {
order: number // Unique order of this node's execution in the flow
type: string // Constructor name of the node (e.g., "MyCustomNode", "Flow")
triggered: Record<Action, ExecutionTree[]> | null
// An object where keys are action names triggered by this node.
// Values are arrays of ExecutionTree(s) for the successor node(s)
// that were executed due to that action.
// `null` if the node was terminal for its branch or did not trigger actions
// that led to further node executions visible in this tree.
// (Note: Even if a node doesn't explicitly trigger, a 'default' action might be
// processed, leading to an empty array if no successor for 'default').
}In Python, it's a TypedDict with similar fields: order: int, type: str, triggered: Optional[Dict[Action, List[ExecutionTree]]].
Benefits of ExecutionTree:
Debugging: Trace exactly which nodes ran, in what order, and which actions were triggered. This is invaluable for understanding why a flow took a particular path.
Visualization: The tree structure can be directly used to generate visual diagrams of the execution path (see below).
Auditing & Logging: Store the
ExecutionTree(e.g., as JSON) for auditing purposes or detailed logging of a specific flow run.Performance Analysis: While not its primary purpose, you could augment nodes to record timing information and include it in a custom
ExecutionTreeor a parallel logging structure to identify bottlenecks.
Logging Best Practices
While the ExecutionTree provides a structural log, you can complement it with traditional logging:
Integrate Your Preferred Logger: Use standard logging libraries (Python's
logging,pino/winstonin TS).Log in Node Lifecycle Methods: Add log statements in
prep,exec, andpostto capture:Node entry/exit.
Key data being read from or written to
Memory.Important decisions made or results computed.
Actions being triggered in
post.
Contextual Information: Include node ID (
self._node_order/this.__nodeOrder), node type, and relevantMemorykeys in your log messages.Error Logging: Ensure
execFallbacklogs detailed error information before returning a fallback or re-throwing.
Example: Python Logging with ExecutionTree
ExecutionTreeVisualization
The ExecutionTree is well-suited for generating visualizations of a specific run of your flow.
1. Visualizing the Static Flow Definition
This code recursively traverses the nested graph, assigns unique IDs to each node, and treats Flow nodes as subgraphs to generate Mermaid syntax for a hierarchical visualization.
For example, suppose we have a complex Flow for data science:
The code generates a Mermaid diagram:
2. Visualizing Runtime Execution from ExecutionTree
ExecutionTreeYou can write a script to traverse the ExecutionTree and generate a graph definition for tools like Mermaid, Graphviz (DOT language), or JavaScript graph libraries (e.g., Vis.js, Cytoscape.js).
Example: Generating Mermaid from ExecutionTree (Conceptual Python)
This script would output Mermaid syntax representing the actual path taken during that specific flow.run().
By combining structured logging (from your nodes) with the ExecutionTree, you gain powerful tools for understanding, debugging, and monitoring your Caskada applications.
3. Call Stack Debugging
For debugging purposes, it's useful to inspect the runtime call stack to understand the execution path through your nodes. This implementation extracts the Node call stack by examining the current execution frames:
For example, suppose we have a complex Flow for data science:
The output would be: Call stack: ['EvaluateModelNode', 'ModelFlow', 'DataScienceFlow']
This shows the nested execution path, with the current node (EvaluateModelNode) at the top, followed by its parent flows.
Last updated