langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-23 21:15:32 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

The output node in the loop node is inconsistent with the final output content #19848

New Issue
Closed
opened 2026-02-21 20:04:31 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 20:04:31 -05:00
Owner
Copy Link
Copy Source

Originally created by @yuzai-code on GitHub (Oct 23, 2025).

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.9.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I'm getting different output when configuring the LLM node in a loop and when using the Output node directly.

The final output is: (The loop repeats three times. The first two outputs repeat the first output. However, the Output node clearly outputs different outputs three times.)

✔️ Expected Behavior

The content of the final response output should be consistent with the content in the output node

❌ Actual Behavior

No response

Originally created by @yuzai-code on GitHub (Oct 23, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.9.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I'm getting different output when configuring the LLM node in a loop and when using the Output node directly. The final output is: (The loop repeats three times. The first two outputs repeat the first output. However, the Output node clearly outputs different outputs three times.) ### ✔️ Expected Behavior The content of the final response output should be consistent with the content in the output node ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 20:04:31 -05:00
yindo closed this issue 2026-02-21 20:04:31 -05:00
yindo commented 2026-02-21 20:04:32 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 23, 2025):

Hi @yuzai-code! I'm Dosu and I’m helping the dify team.

This is a known limitation in Dify workflows: outputs from nodes inside a loop are not automatically available as outputs for downstream nodes unless you explicitly define and assign them as loop variables in the loop node’s configuration. The workflow engine scopes variable visibility for determinism and safety, so outputs from sibling nodes in the same iteration aren’t available for assignment in real time. This can lead to the kind of inconsistency you’re seeing between loop node outputs and the final output node, especially if intermediate results are not properly assigned to loop variables or are overwritten during iterations. The recommended workaround is to ensure your code or LLM node writes its output directly to a loop variable by explicit assignment within the loop logic—typically using a Variable Assigner node that targets the loop variable. If your workflow depends on dynamic assignment inside loops, you may need to restructure it so the needed value is available as an input to the loop, not as a sibling output. This limitation is discussed in detail in this issue and comment.

Recent pull requests have improved loop variable handling, but this specific assignment and output propagation issue is not fully resolved in v1.9.1. If possible, consider upgrading to a newer version, as improvements are ongoing. For now, double-check your loop variable assignments and ensure outputs are explicitly routed to loop variables to avoid inconsistencies between loop and output nodes.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 23, 2025): <!-- Greeting --> Hi @yuzai-code! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> This is a known limitation in Dify workflows: outputs from nodes inside a loop are not automatically available as outputs for downstream nodes unless you explicitly define and assign them as loop variables in the loop node’s configuration. The workflow engine scopes variable visibility for determinism and safety, so outputs from sibling nodes in the same iteration aren’t available for assignment in real time. This can lead to the kind of inconsistency you’re seeing between loop node outputs and the final output node, especially if intermediate results are not properly assigned to loop variables or are overwritten during iterations. The recommended workaround is to ensure your code or LLM node writes its output directly to a loop variable by explicit assignment within the loop logic—typically using a Variable Assigner node that targets the loop variable. If your workflow depends on dynamic assignment inside loops, you may need to restructure it so the needed value is available as an input to the loop, not as a sibling output. This limitation is discussed in detail in [this issue and comment](https://github.com/langgenius/dify/issues/21225#issuecomment-2987247087). Recent pull requests have improved loop variable handling, but this specific assignment and output propagation issue is not fully resolved in v1.9.1. If possible, consider upgrading to a newer version, as improvements are ongoing. For now, double-check your loop variable assignments and ensure outputs are explicitly routed to loop variables to avoid inconsistencies between loop and output nodes. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/a313bce7-6789-4a8b-90d1-f2409537ecaa?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/a313bce7-6789-4a8b-90d1-f2409537ecaa?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/a313bce7-6789-4a8b-90d1-f2409537ecaa?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/a313bce7-6789-4a8b-90d1-f2409537ecaa?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/a313bce7-6789-4a8b-90d1-f2409537ecaa?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/a313bce7-6789-4a8b-90d1-f2409537ecaa?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/a313bce7-6789-4a8b-90d1-f2409537ecaa?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27326)
yindo commented 2026-02-21 20:04:32 -05:00
Author
Owner
Copy Link
Copy Source

@yuzai-code commented on GitHub (Oct 23, 2025):

one:

two:

I am not using loop variables. I am using a loop where each LLM outputs something different in each loop. The three results in the output node of the workflow are different each time, but the final result is that the second result is exactly the same as the first, and the third result is the second.

     原始邮件

发件人：dosubot[bot] @.>
发件时间：2025年10月23日 14:37
收件人：958684803 @.>
抄送：Yuzai @.>, Mention @.>
主题：Re: [langgenius/dify] The output node in the loop node isinconsistent with the final output content (Issue #27326)

dosubot[bot] left a comment (langgenius/dify#27326)

Hi @yuzai-code! I'm Dosu and I’m helping the dify team.

This is a known limitation in Dify workflows: outputs from nodes inside a loop are not automatically available as outputs for downstream nodes unless you explicitly define and assign them as loop variables in the loop node’s configuration. The workflow engine scopes variable visibility for determinism and safety, so outputs from sibling nodes in the same iteration aren’t available for assignment in real time. This can lead to the kind of inconsistency you’re seeing between loop node outputs and the final output node, especially if intermediate results are not properly assigned to loop variables or are overwritten during iterations. The recommended workaround is to ensure your code or LLM node writes its output directly to a loop variable by explicit assignment within the loop logic—typically using a Variable Assigner node that targets the loop variable. If your workflow depends on dynamic assignment inside loops, you may need to restructure it so the needed value is available as an input to the loop, not as a sibling output. This limitation is discussed in detail in this issue and comment.

Recent pull requests have improved loop variable handling, but this specific assignment and output propagation issue is not fully resolved in v1.9.1. If possible, consider upgrading to a newer version, as improvements are ongoing. For now, double-check your loop variable assignments and ensure outputs are explicitly routed to loop variables to avoid inconsistencies between loop and output nodes.

To reply, just mention @dosu.

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

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

@yuzai-code commented on GitHub (Oct 23, 2025): one: two: I&nbsp;am not using loop variables. I am using a loop where each LLM outputs something different in each loop. The three results in the output node of the workflow are different each time, but the final result is that the second result is exactly the same as the first, and the third result is the second. 原始邮件 发件人：dosubot[bot] ***@***.***&gt; 发件时间：2025年10月23日 14:37 收件人：958684803 ***@***.***&gt; 抄送：Yuzai ***@***.***&gt;, Mention ***@***.***&gt; 主题：Re: [langgenius/dify] The output node in the loop node isinconsistent with the final output content (Issue #27326) dosubot[bot] left a comment (langgenius/dify#27326) Hi @yuzai-code! I'm Dosu&nbsp;and I’m helping the dify team. This is a known limitation in Dify workflows: outputs from nodes inside a loop are not automatically available as outputs for downstream nodes unless you explicitly define and assign them as loop variables in the loop node’s configuration. The workflow engine scopes variable visibility for determinism and safety, so outputs from sibling nodes in the same iteration aren’t available for assignment in real time. This can lead to the kind of inconsistency you’re seeing between loop node outputs and the final output node, especially if intermediate results are not properly assigned to loop variables or are overwritten during iterations. The recommended workaround is to ensure your code or LLM node writes its output directly to a loop variable by explicit assignment within the loop logic—typically using a Variable Assigner node that targets the loop variable. If your workflow depends on dynamic assignment inside loops, you may need to restructure it so the needed value is available as an input to the loop, not as a sibling output. This limitation is discussed in detail in this issue and comment. Recent pull requests have improved loop variable handling, but this specific assignment and output propagation issue is not fully resolved in v1.9.1. If possible, consider upgrading to a newer version, as improvements are ongoing. For now, double-check your loop variable assignments and ensure outputs are explicitly routed to loop variables to avoid inconsistencies between loop and output nodes. To reply, just mention @dosu. How did I do? Good&nbsp;| Irrelevant&nbsp;| Incorrect&nbsp;| Verbose&nbsp;| Hallucination&nbsp;| Report 🐛&nbsp;| Other&nbsp; &nbsp;&nbsp; — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
yindo commented 2026-02-21 20:04:32 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 23, 2025):

This behavior is a known limitation in Dify v1.9.1. When you don't use loop variables, the workflow engine does not automatically aggregate or preserve each iteration's unique output for the final output node. Instead, outputs from each loop iteration can overwrite each other, so only the last (or sometimes duplicated) value is visible to downstream nodes—regardless of what you see in the Output node inside the loop. This is why your final output shows repeated or overwritten results, even though each LLM node in the loop produced something different and the Output node displayed them correctly during execution.

To get the correct, distinct outputs from each iteration in your final result, you need to explicitly define a loop variable (for example, an array) in the loop node configuration and assign each LLM output to it within the loop. This is the only reliable way to pass all iteration results downstream in Dify's current workflow engine. Without this, the final output node cannot access the full set of per-iteration outputs—only the last or an incorrectly aggregated value.

This limitation and the need for explicit loop variables are discussed in detail in this issue and comment and here. Recent versions have improved some aspects of loop output handling, but this specific issue is not fully resolved in v1.9.1. If possible, consider restructuring your workflow to use loop variables, or upgrading to a newer version if fixes become available.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 23, 2025): <!-- Answer --> This behavior is a known limitation in Dify v1.9.1. When you don't use loop variables, the workflow engine does not automatically aggregate or preserve each iteration's unique output for the final output node. Instead, outputs from each loop iteration can overwrite each other, so only the last (or sometimes duplicated) value is visible to downstream nodes—regardless of what you see in the Output node inside the loop. This is why your final output shows repeated or overwritten results, even though each LLM node in the loop produced something different and the Output node displayed them correctly during execution. To get the correct, distinct outputs from each iteration in your final result, you need to explicitly define a loop variable (for example, an array) in the loop node configuration and assign each LLM output to it within the loop. This is the only reliable way to pass all iteration results downstream in Dify's current workflow engine. Without this, the final output node cannot access the full set of per-iteration outputs—only the last or an incorrectly aggregated value. This limitation and the need for explicit loop variables are discussed in detail in [this issue and comment](https://github.com/langgenius/dify/issues/21225#issuecomment-2987247087) and [here](https://github.com/langgenius/dify/issues/26666). Recent versions have improved some aspects of loop output handling, but this specific issue is not fully resolved in v1.9.1. If possible, consider restructuring your workflow to use loop variables, or upgrading to a newer version if fixes become available. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/f3fbc862-453e-43dd-9768-cd8fe95b3dbf?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/f3fbc862-453e-43dd-9768-cd8fe95b3dbf?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/f3fbc862-453e-43dd-9768-cd8fe95b3dbf?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/f3fbc862-453e-43dd-9768-cd8fe95b3dbf?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/f3fbc862-453e-43dd-9768-cd8fe95b3dbf?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/f3fbc862-453e-43dd-9768-cd8fe95b3dbf?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/f3fbc862-453e-43dd-9768-cd8fe95b3dbf?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27326)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#19848
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?