[Bug] Variable Assigner node silently fails for legacy V1 data format - backward compatibility issue

[kinglisky]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.10.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Bug Description

Legacy workflow data containing Variable Assigner nodes in V1 format fails to execute the assignment operation silently. The node execution reports success, but no actual variable assignment occurs.

The root cause is that DifyNodeFactory.create_node() always uses LATEST_VERSION to instantiate node classes, ignoring the version field in node data. When V1 format data (without version and items fields) is processed by VariableAssignerNodeV2, the items field defaults to an empty list, causing the _run() method's for-loop to skip all operations.

Steps to Reproduce

1. Import or use a legacy workflow that was created before the Variable Assigner V2 upgrade
2. The legacy Variable Assigner node data contains:

   {
     "data": {
       "assigned_variable_selector": ["conversation", "query"],
       "input_variable_selector": ["sys", "query"],
       "write_mode": "append",
       "type": "assigner"
       // Missing: "version": "2" and "items": [...]
     }
   }

3. Run the workflow with a conversation variable list append operation
4. The Variable Assigner node completes without error, but the list variable is not updated

Example

Use the following example：
Variable Assigner Test.yml

The normal operating result is as follows：

✔️ Expected Behavior

Expected Behavior

• The system should either:

  1. Select VariableAssignerNodeV1 class based on missing version field (backward compatibility), OR
  2. VariableAssignerNodeV2 should auto-migrate V1 data format by converting assigned_variable_selector, input_variable_selector, and write_mode to equivalent items array

• The variable assignment should execute correctly regardless of data format version

❌ Actual Behavior

Actual Behavior

• The node execution returns WorkflowNodeExecutionStatus.SUCCEEDED
• No variable assignment actually occurs
• No error message is displayed to the user
• Re-editing the node in the UI "fixes" the issue by saving in V2 format

[kinglisky]

Root Cause Analysis

File: api/core/workflow/nodes/node_factory.py (Line 67)

node_class = node_mapping.get(LATEST_VERSION)  # Always uses latest version

File: api/core/workflow/nodes/node_mapping.py (Lines 120-124)

NodeType.VARIABLE_ASSIGNER: {
    LATEST_VERSION: VariableAssignerNodeV2,
    "1": VariableAssignerNodeV1,
    "2": VariableAssignerNodeV2,
},

File: api/core/workflow/nodes/variable_assigner/v2/entities.py (Lines 24-26)

class VariableAssignerNodeData(BaseNodeData):
    version: str = "2"
    items: Sequence[VariableOperationItem] = Field(default_factory=list)  # Defaults to empty

File: api/core/workflow/nodes/variable_assigner/v2/node.py (Line 104)

for item in self.node_data.items:  # Empty list = no iterations = no assignment

Data Format Comparison

Field	V1 (Legacy)	V2 (Current)
version	❌ Missing	✅ "2"
items	❌ Missing	✅ Array of operations
assigned_variable_selector	✅ Present	✅ Present (legacy)
input_variable_selector	✅ Present	✅ Present (legacy)
write_mode	✅ Present	✅ Present (legacy)

Suggested Fix

Option 1: Version-aware node instantiation in DifyNodeFactory:

def create_node(self, node_config: dict[str, object]) -> Node:
    # ... existing code ...
    node_data = node_config.get("data", {})
    data_version = node_data.get("version", "1")  # Default to V1 for legacy data
    node_class = node_mapping.get(data_version) or node_mapping.get(LATEST_VERSION)
    # ...

Option 2: Add V1 data migration in VariableAssignerNodeData validator:

class VariableAssignerNodeData(BaseNodeData):
    @model_validator(mode="before")
    @classmethod
    def migrate_v1_data(cls, values):
        if "items" not in values and "assigned_variable_selector" in values:
            # Auto-migrate V1 format to V2
            values["items"] = [{
                "variable_selector": values["assigned_variable_selector"],
                "input_type": "variable",
                "operation": values.get("write_mode", "over-write").replace("-", "_"),
                "value": values["input_variable_selector"]
            }]
        return values

[dosubot]

Hi @kinglisky! I'm Dosu and I’m helping the dify team.

Your root cause analysis is spot on: the factory always instantiates the latest node version, so legacy Variable Assigner nodes (V1 data) get processed by V2 logic, which expects an items array and silently skips assignment if it's missing. This is confirmed by the current implementation of DifyNodeFactory.create_node() and the node mapping structure, which ignores the version field in node data and always uses the class registered as LATEST_VERSION for each node type (source) (source).

Both of your suggested fixes are valid:

• Option 1 (version-aware instantiation): Updating the factory to select the node class based on the version field in node data (with a sensible default for legacy data) would restore backward compatibility for old workflows. This approach is already used for some other node types to maintain compatibility with historical data (source).

• Option 2 (V1-to-V2 migration): Adding a migration validator to the V2 data model would allow legacy V1 data to be auto-converted to the new format at runtime, ensuring assignments work even if the node is always instantiated as V2. This is a robust solution if you want to keep the factory logic simple, but the migration must be precise to avoid mutating valid V2 configs.

Combining both approaches would maximize stability and compatibility, especially for mixed or partially migrated workflows. Whichever fix you choose, regression testing is important to ensure no side effects for other node types or new workflows. There is currently no migration logic in place, and recent PRs have only addressed naming and unrelated logic, not this compatibility gap.

Let me know if you want implementation tips or have questions about edge cases!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}