Variable Assigner inside loop cannot reference loop variable, causing 'Variable not found' error (v1.16.0)

[caomuyunshui]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

Dify version

1.16.0

Steps to Reproduce

1. Create a workflow (or a snippet) that contains a Loop node.
2. In the Loop node, define a loop variable, e.g., ii with an initial value of false.
3. Inside the loop, add a Variable Assigner node that is supposed to update this loop variable (ii) to a new value (e.g., true).
4. Export this workflow as a snippet or run it directly.
5. Upon execution, the Variable Assigner node fails with the error:

   Variable ['<loop_node_id>', 'ii'] not found
   

✔️ Expected Behavior

According to the official Dify documentation, Variable Assigner nodes support assigning values to loop variables. The Variable Assigner node inside the loop should be able to reference and update the loop variable (ii) without any errors. The workflow should run successfully and exit the loop when the termination condition is met.

❌ Actual Behavior

The workflow execution fails with a Variable not found error for the loop variable ii. The Variable Assigner node cannot resolve the reference to the loop variable, even though it is defined in the parent Loop node.

Note: A manually built workflow (via drag-and-drop) with the same logic works correctly. The issue appears to be specifically triggered when the workflow is imported or parsed as a snippet, where the internal variable references (especially absolute paths like ['<loop_node_id>', 'ii']) are not correctly re-established.

Error Log

Variable ['1785502567464', 'ii'] not found

带变量赋值.yml
启动Word服务-不带变量赋值.yml

[dosubot[bot]]

@caomuyunshui, this looks like a snippet variable remapping bug. Here's what I found:

Root cause: When a snippet is inserted into a workflow, all node IDs are regenerated and variable references are remapped via remapSnippetNodeVariableReferences, which relies on getNodeUsedVars() to discover variable selectors in each node [1]. However, getNodeUsedVars() for VariableAssigner nodes only reads the top-level variables field — it does not traverse the v2 items[].variable_selector or items[].value fields [2]. This means when your snippet is inserted and the Loop node gets a new ID, the Variable Assigner's items[].value reference (e.g., ['old_loop_id', 'ii']) is not remapped to use the new loop node ID, resulting in the Variable not found error at runtime.

This explains why manually building the same workflow works — the IDs are consistent when you create it by hand, but snippet insertion breaks the reference.

This is a known gap. PR #39843 recently fixed snippet variable remapping for many node types but did not cover the v2 Variable Assigner items[] structure [3].

Workaround: After inserting the snippet, open the Variable Assigner node inside the Loop, clear its variable reference, and re-select the loop variable from the picker. This will re-establish the reference with the correct (new) loop node ID.

There's also a potentially related older issue (#38246) where Variable Assigner nodes inside Loops could be missing parentId metadata, causing them to be silently excluded from execution [4]. If the workaround above doesn't resolve it, check whether the Variable Assigner node in your exported DSL has parentId set to the Loop node's ID.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Mike-stone12]

An independent minimal snippet reproduces the stale-reference failure during insertion: Dify regenerates node IDs, but getNodeUsedVars has no BlockEnum.Assigner (type: assigner) case, so the v2 assignment targets and variable inputs retain their original IDs. The similarly named BlockEnum.VariableAssigner case covers a different node type. A focused fix can remap current and legacy assigner selectors at the insertion boundary while preserving constants and references outside the snippet. This remaining assigner-specific gap is tracked in #42227, with the focused fix and regression tests in #42229.