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

Reverting #11271 as it's causing serious unexpected behavior of iteration node when parallel mode #7048

New Issue
Closed
opened 2026-02-21 18:18:36 -05:00 by yindo · 4 comments
yindo commented 2026-02-21 18:18:36 -05:00
Owner
Copy Link
Copy Source

Originally created by @kazuhisa-wada on GitHub (Dec 4, 2024).

Originally assigned to: @Nov1c444 on GitHub.

Self Checks

  • 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 (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.13.0

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

I strongly believe this is serious bug and so please revert this PR: #11271 ASAP as I have confirmed this issue does NOT happen after revert.

Steps to reproduce

The workflows which have parallel mode iteration blocks consisting of time-consuming(maybe >60sec) workload loads with parallel mode stops immediately and then no progress happens eventually.

Simple cases where this bug happends :

  1. Iteration node with 5 parallel mode, which includes 5 parallel code block where just 60seconds of sleep is executed , stops immediately and then trace log just shows '0 iterations'.
    image

  2. Iteration node with 5 parallel mode, which includes 5 parallel code LLM node(each takes >60seconds), stops immediately and then trace log just shows '0 iterations'.
    image

Also, this issue never happens once this PR: #11271 is reverted. I have confirmed this in local source code build mode.

✔️ Expected Behavior

Iteration node should NOT stop and should work normally.

❌ Actual Behavior

The workflows, which have parallel mode iteration blocks consisting of time-consuming(maybe >60sec) workload loads with parallel mode, stops immediately and then no progress happens eventually.

Please see the concrete cases in Steps to reproduce section.

Originally created by @kazuhisa-wada on GitHub (Dec 4, 2024). Originally assigned to: @Nov1c444 on GitHub. ### Self Checks - [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 (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [X] Please do not modify this template :) and fill in all the required fields. ### Dify version 0.13.0 ### Cloud or Self Hosted Self Hosted (Source) ### Steps to reproduce I strongly believe this is serious bug and so please revert this PR: #11271 ASAP as I have confirmed this issue does NOT happen after revert. **Steps to reproduce** The workflows which have parallel mode iteration blocks consisting of time-consuming(maybe >60sec) workload loads with parallel mode stops immediately and then no progress happens eventually. Simple cases where this bug happends : 1. Iteration node with 5 parallel mode, which includes 5 parallel code block where just 60seconds of sleep is executed , stops immediately and then trace log just shows '0 iterations'. ![image](https://github.com/user-attachments/assets/2ccc3097-6c5c-4919-9cd0-a0a2761da70f) 2. Iteration node with 5 parallel mode, which includes 5 parallel code LLM node(each takes >60seconds), stops immediately and then trace log just shows '0 iterations'. ![image](https://github.com/user-attachments/assets/cffe9964-0bac-4124-83e5-b1c5e82d5d55) Also, this issue never happens once this PR: #11271 is reverted. I have confirmed this in local source code build mode. ### ✔️ Expected Behavior Iteration node should NOT stop and should work normally. ### ❌ Actual Behavior The workflows, which have parallel mode iteration blocks consisting of time-consuming(maybe >60sec) workload loads with parallel mode, stops immediately and then no progress happens eventually. Please see the concrete cases in Steps to reproduce section.
yindo added the 🐞 bug label 2026-02-21 18:18:36 -05:00
yindo closed this issue 2026-02-21 18:18:36 -05:00
yindo commented 2026-02-21 18:18:36 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 4, 2024):

The issue you're experiencing with the iteration node in parallel mode seems to be related to the changes introduced in PR #11271. This PR added a method _run_single_iter_parallel to handle parallel execution by creating copies of the graph engine and variable pool for each parallel run. It uses a unique parallel_mode_run_id to manage these executions [1].

The problem you're encountering, where the iteration node stops immediately with time-consuming tasks, might be due to how these parallel executions are managed or a potential timeout setting that isn't documented. Since reverting the PR resolves the issue, it suggests that the changes in the PR are directly affecting the behavior of the iteration node under these conditions.

To address this, you might consider investigating the specific implementation of _run_single_iter_parallel to identify any constraints or conditions that could lead to premature termination of tasks. Additionally, checking for any undocumented timeout settings or error handling mechanisms in the parallel execution logic could provide further insights.

To continue talking to Dosu, mention @dosu.

@dosubot[bot] commented on GitHub (Dec 4, 2024): <!-- Answer --> The issue you're experiencing with the iteration node in parallel mode seems to be related to the changes introduced in PR #11271. This PR added a method `_run_single_iter_parallel` to handle parallel execution by creating copies of the graph engine and variable pool for each parallel run. It uses a unique `parallel_mode_run_id` to manage these executions <sup>[[1]](https://github.com/langgenius/dify/blob/main/api/core/workflow/nodes/iteration/iteration_node.py)</sup>. The problem you're encountering, where the iteration node stops immediately with time-consuming tasks, might be due to how these parallel executions are managed or a potential timeout setting that isn't documented. Since reverting the PR resolves the issue, it suggests that the changes in the PR are directly affecting the behavior of the iteration node under these conditions. To address this, you might consider investigating the specific implementation of `_run_single_iter_parallel` to identify any constraints or conditions that could lead to premature termination of tasks. Additionally, checking for any undocumented timeout settings or error handling mechanisms in the parallel execution logic could provide further insights. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.*
yindo commented 2026-02-21 18:18:36 -05:00
Author
Owner
Copy Link
Copy Source

@kazuhisa-wada commented on GitHub (Dec 4, 2024):

I understand this issue may be related to timeout at main thread, however, the workflows I said worked without any problem until v.0.13.0 was released and also I've confirmed the revert has made the issue not happen any more.

Then, I do not think further investigation on timeous is required here. Right way should be to revisit the way to fix the intent of #11271 and also test should be done correctly there.

@kazuhisa-wada commented on GitHub (Dec 4, 2024): I understand this issue may be related to timeout at main thread, however, the workflows I said worked without any problem until v.0.13.0 was released and also I've confirmed the revert has made the issue not happen any more. Then, I do not think further investigation on timeous is required here. Right way should be to revisit the way to fix the intent of #11271 and also test should be done correctly there.
yindo commented 2026-02-21 18:18:36 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Dec 4, 2024):

We are working on this.

@crazywoola commented on GitHub (Dec 4, 2024): We are working on this.
yindo commented 2026-02-21 18:18:37 -05:00
Author
Owner
Copy Link
Copy Source

@Nov1c444 commented on GitHub (Dec 4, 2024):

Thank you very much for your feedback, and I sincerely apologize. When sharing the thread pool between iteration nodes and the entire graph, I failed to consider that the iteration thread pool would occupy all available workers, preventing parallel nodes within iterations from being allocated workers and thus causing iterations to fail to execute. I apologize again for any inconvenience caused by my oversight.

@Nov1c444 commented on GitHub (Dec 4, 2024): Thank you very much for your feedback, and I sincerely apologize. When sharing the thread pool between iteration nodes and the entire graph, I failed to consider that the iteration thread pool would occupy all available workers, preventing parallel nodes within iterations from being allocated workers and thus causing iterations to fail to execute. I apologize again for any inconvenience caused by my oversight.
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#7048
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?