Principle:FlowiseAI Flowise Edge Connection
| Attribute | Value |
|---|---|
| Source Repository | FlowiseAI/Flowise |
| Domain | Chatflow_Creation |
| Workflow | Chatflow_Creation |
| Last Updated | 2026-02-12 |
Overview
Technique for establishing validated connections between nodes in a directed acyclic graph (DAG) flow editor. In a visual flow editor, users connect output handles of one node to input handles of another. The connection system must validate type compatibility, prevent duplicate connections to single-input anchors, allow list-type anchors to accept multiple connections, and update the target node's input data with a reference to the source node.
Motivation
Connections between nodes define the data flow through the chatflow graph. Without a robust connection system:
- Users could create invalid connections between incompatible node types (e.g., connecting a chat model output to an input that expects a vector store).
- Single-input anchors could receive multiple connections, causing ambiguous data flow.
- The target node would not know which source node provides its input data, breaking the execution pipeline.
- Circular dependencies could be introduced, making the graph impossible to execute.
A validated connection system ensures that only semantically correct and structurally valid edges can be created.
Description
The Edge Connection principle implements type-compatible graph edge creation with constraint checking. The process involves three phases: validation, state update, and edge creation.
Connection Validation
When a user drags a connection from a source handle to a target handle, the system validates compatibility:
- Extract type information -- Source and target handle IDs encode type information in their last segment. For example,
chatOpenAI_0-output-chatOpenAI-BaseChatModel|BaseLanguageModelencodes the output types["BaseChatModel", "BaseLanguageModel"]. - Check type intersection -- The system checks if any source type matches any target type. A connection is valid if there is at least one common type between the source's output base classes and the target's accepted input types.
- Check single-input constraint -- For non-list anchors, the system verifies that no existing edge already connects to the same target handle. List-type anchors (marked with
list: true) can accept multiple connections. - Cycle detection -- For agentflow connections, a graph traversal checks whether adding the proposed edge would create a cycle, maintaining the DAG invariant.
Target Node State Update
When a valid connection is made, the target node's input data must be updated:
- Single input anchors -- The input value is set to
Template:SourceNodeId.data.instance, a template reference resolved at execution time. - List input anchors -- The source reference is appended to an array of values. For tool inputs, a special ordering function ensures specific tools (e.g., RequestsGet, RequestsPost) are ordered before others.
- Variable-accepting parameters -- If the input is a parameter that accepts variables (not an anchor), the source reference is appended to the existing string value.
Handle ID Format
Handle IDs follow a structured format that encodes connection metadata:
// Source handle format:
"{nodeId}-output-{outputName}-{baseClasses joined by |}"
// Example: "chatOpenAI_0-output-chatOpenAI-BaseChatModel|BaseLanguageModel"
// Target handle format:
"{nodeId}-input-{inputName}-{acceptedTypes joined by |}"
// Example: "llmChain_0-input-model-BaseLanguageModel"
Theoretical Basis
This principle is based on type-compatible graph edge creation in a directed acyclic graph:
- Type intersection validation -- Connection compatibility is determined by set intersection between the source's output types and the target's accepted types. This is analogous to interface compatibility in type systems, where a connection is valid if the source "implements" at least one type the target "requires."
- Handle ID encoding -- Embedding type information in handle IDs is a denormalization strategy that enables O(1) type checking during connection validation without additional node lookups.
- Single-assignment vs. multi-assignment -- Anchors without the
listflag follow single-assignment semantics (at most one connection), while list anchors follow multi-assignment semantics (any number of connections). This distinction maps to the difference between a scalar input and a collection input in the node's execution model. - DAG constraint -- The cycle detection algorithm performs a depth-first search from the target to the source in the existing graph. If a path exists, adding the proposed edge would create a cycle, and the connection is rejected. This maintains the topological ordering required for sequential execution.
Usage
Use this principle when implementing node connection logic in a visual DAG editor with typed connection handles. It applies to:
- Creating edges between output anchors and input anchors in a flow graph.
- Validating type compatibility between source outputs and target inputs.
- Managing single-input vs. list-input connection semantics.
- Preventing cyclic dependencies in directed flow graphs.