Partial Graph Execution for Efficient Workflow Testing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In graphical execution workflows, users often need to test modified portions of a graph, but executing the entire graph is inefficient, especially when changes are minor or when certain modules have side-effects or are non-deterministic, leading to excessive re-execution of unnecessary parts.
Innovation Solution
A method that allows users to select and execute a sub-portion of an executable graph independently, using cached data, user input, or random values, while excluding unnecessary modules and halting execution at the user-defined boundary, thereby enabling quick iterations and controlling deterministic behavior.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the entire graph is re-executed to test modified portions, then data consistency is maintained, but execution time increases significantly
Solution Approach 1:
The patent divides the graph execution into segments by introducing a execution context that tracks which modules have been executed. This allows the system to identify and execute only the necessary segments (modules) required to reach the modified portions, rather than re-executing the entire graph. The execution context maintains state information about executed modules, enabling partial graph execution while preserving data consistency.
Solution Approach 2:
The patent implements partial action by allowing users to specify target modules and executing only the minimal subset of modules needed to reach those targets. The system calculates the required execution set by traversing the graph from root modules to target modules, executing only those necessary modules. This partial execution approach maintains reliability for the tested portions while avoiding unnecessary re-execution of other parts.
2Reliability
If the entire graph is re-executed to test modified portions, then all data dependencies are satisfied, but computational resources are wasted
Solution Approach 1:
The execution context segments the graph into executed and unexecuted portions by tracking module execution state. This segmentation enables the system to identify exactly which modules need to run to satisfy data dependencies for the target modules, avoiding unnecessary computation in modules whose data is already available or not needed for the current test.
Solution Approach 2:
The patent extracts and reuses cached data from previously executed modules. When a module's output is needed and it has already been executed, the system retrieves the cached data instead of re-executing the module. This extraction of useful data from the execution context eliminates redundant computational work while maintaining data dependency satisfaction.
3Reliability
If modules with side-effects are executed repeatedly, then comprehensive testing is achieved, but unintended consequences occur
Solution Approach 1:
The patent applies partial action by limiting execution to only the modules necessary to reach the target modules. Modules with side-effects are executed only when they are ancestors of the target modules in the graph, not repeatedly throughout the entire graph. This controlled partial execution achieves sufficient testing coverage for the modified portions while avoiding unintended consequences from repeated side-effect execution.
Solution Approach 2:
The system performs preliminary analysis to determine the minimal execution set before actually executing modules. By calculating which modules are required to reach the targets and checking the execution context for previously executed modules, the system prepares a precise execution plan that avoids unnecessary re-execution of modules with side-effects, thereby preventing unintended consequences.
Data Source
AI summary
Executing a user selected portion of an executable graph, the method includes, for an executable graph, the executable graph comprising executable modules, identifying a user selected sub-portion of the executable graph. The method further includes determining that data is needed from upstream modules in the graph to execute the sub-portion of the executable graph. The method further includes obtaining the needed data. The method further includes executing the user selected sub-portion of the graph in isolation from other portions of the executable graph. This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.