Graph Processing is the subsystem responsible for converting flow definitions into validated, executable graph structures. This system bridges the gap between stored flow data (JSON representations) and the runtime execution engine by constructing graph objects, validating their structure, resolving execution order through topological sorting, and preparing them for vertex-by-vertex execution.
The processing pipeline involves both frontend validation (edge cleaning, connection checking) and backend graph construction (cycle detection, vertex ordering).
Sources: src/lfx/src/lfx/custom/custom_component/component.py76-112; src/frontend/src/utils/__tests__/cleanEdges.test.ts103-121
Before a flow is sent to the backend for execution, the frontend performs rigorous validation of the graph structure. The cleanEdges utility is critical for ensuring that connections remain valid as components evolve or are updated.
The cleanEdges function iterates through all edges and verifies that:
ModelInput types which default based on model_type (e.g., "embedding" maps to Embeddings, "language" maps to LanguageModel) src/frontend/src/utils/__tests__/cleanEdges.test.ts177-188Connection validation prevents invalid graph states during the design phase:
proxy connections where one input acts as a gateway for another src/frontend/src/utils/__tests__/cleanEdges.test.ts222-224loop_types src/frontend/src/utils/__tests__/cleanEdges.test.ts205-207Sources: src/frontend/src/utils/__tests__/cleanEdges.test.ts103-240; src/frontend/src/stores/__tests__/flowStore.test.ts132-151
The backend maps JSON structures to Graph and Vertex entities, establishing the topology required for execution.
This diagram illustrates the transition from raw frontend data to a structured, executable backend graph, incorporating the Component initialization logic.
The Component class (inheriting from CustomComponent) initializes the internal state required for the graph:
_inputs: A dictionary of InputTypes src/lfx/src/lfx/custom/custom_component/component.py132_outputs_map: A mapping of output names to Output objects src/lfx/src/lfx/custom/custom_component/component.py133_edges: A list of EdgeData representing connections src/lfx/src/lfx/custom/custom_component/component.py136Sources: src/lfx/src/lfx/custom/custom_component/component.py113-183; src/backend/base/langflow/schema/schema.py1-24
Execution order is determined by resolving the dependencies defined by the edges.
The useFlowStore manages the build state for every node in the graph using the flowBuildStatus object src/frontend/src/stores/__tests__/flowStore.test.ts138
isBuilding and isPending flags src/frontend/src/stores/__tests__/flowStore.test.ts141-142hasIO flag src/frontend/src/stores/__tests__/flowStore.test.ts149A critical aspect of graph processing is handling concurrent tool invocations. To prevent data corruption (GitHub issue #8791), the ComponentToolkit creates an isolated deepcopy of the component for each tool execution src/lfx/src/lfx/base/tools/component_tool.py98-102 This ensures that _parameters and input values are not overwritten between concurrent runs src/lfx/tests/unit/custom/component/test_concurrent_tool_invocation.py55-61
Sources: src/frontend/src/stores/__tests__/flowStore.test.ts132-169; src/lfx/src/lfx/base/tools/component_tool.py87-131; src/lfx/tests/unit/custom/component/test_concurrent_tool_invocation.py19-52
Graph processing also handles the lifecycle of component code changes and versioning.
When a node is updated, the system triggers a recomputation of the components to update:
registerNodeUpdate and completeNodeUpdate to track asynchronous changes src/frontend/src/stores/__tests__/flowStore.test.ts98-101recomputeComponentsToUpdateIfNeeded identifies if a node's code or template has changed relative to the registry src/frontend/src/stores/__tests__/flowStore.test.ts99During graph execution, data is transformed between types using utility functions:
docs_to_data: Converts LangChain Document objects to Langflow Data src/backend/base/langflow/helpers/data.py14-23data_to_text: Formats Data objects into strings using templates src/backend/base/langflow/helpers/data.py108-121safe_convert: Ensures diverse types (Message, Data, DataFrame) are stringified correctly for vertex inputs src/backend/base/langflow/helpers/data.py166-193Sources: src/frontend/src/stores/__tests__/flowStore.test.ts97-103; src/backend/base/langflow/helpers/data.py26-105; src/backend/base/langflow/schema/artifact.py25-52
This diagram maps conceptual user actions to the specific code symbols that handle them.
Execution results are encapsulated in artifacts and specific schema types:
| Class/Type | Role | Source |
|---|---|---|
ArtifactType | Enum defining types like TEXT, DATA, STREAM, MESSAGE | src/backend/base/langflow/schema/artifact.py15-23 |
Data | Standard container for dictionary-based data and metadata | src/backend/base/langflow/schema/data.py7-9 |
DataFrame | Wrapper for tabular data (pandas-compatible) | src/backend/base/langflow/schema/dataframe.py3 |
OutputValue | Represents the final value produced by a Vertex output | src/backend/base/langflow/schema/schema.py8 |
Sources: src/backend/base/langflow/schema/artifact.py65-82; src/backend/base/langflow/schema/schema.py1-24; src/backend/base/langflow/helpers/data.py195-196
Refresh this wiki