Regarding exceptions in parallel running of nodes #13029

Closed
opened 2026-02-21 19:10:14 -05:00 by yindo · 11 comments
Owner

Originally created by @jasonleelover on GitHub (Apr 16, 2025).

Originally assigned to: @laipz8200, @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

1.2.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

When creating a workflow, I used a problem classifier to classify user input questions and then ran multiple code nodes in parallel, but did not run multiple nodes as expected.

✔️ Expected Behavior

  • When the user inputs' What is the typical range of a gasoline powered car in kilometers', code nodes 1, 2, and 3 should run simultaneously
  • When the user inputs' How many kilometers does an electric car typically have', code nodes 2, 3, and 4 should run simultaneously
  • When the user inputs' How many kilometers does a hydrogen powered vehicle typically have', code nodes 3, 4, and 5 should run simultaneously

Actual Behavior

  • When the user inputs' What is the typical range of a gasoline powered car in kilometers', code nodes 1, 2, and 3 run simultaneously

Image

  • When the user inputs' How many kilometers does an electric car typically have', only code nodes 2, and 3 run simultaneously

Image

  • When the user inputs' How many kilometers does a hydrogen powered vehicle typically have', only code nodes 3 run simultaneously

Image

Originally created by @jasonleelover on GitHub (Apr 16, 2025). Originally assigned to: @laipz8200, @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 1.2.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce When creating a workflow, I used a problem classifier to classify user input questions and then ran multiple code nodes in parallel, but did not run multiple nodes as expected. ### ✔️ Expected Behavior - When the user inputs' What is the typical range of a gasoline powered car in kilometers', code nodes 1, 2, and 3 should run simultaneously - When the user inputs' How many kilometers does an electric car typically have', code nodes 2, 3, and 4 should run simultaneously - When the user inputs' How many kilometers does a hydrogen powered vehicle typically have', code nodes 3, 4, and 5 should run simultaneously ### ❌ Actual Behavior - When the user inputs' What is the typical range of a gasoline powered car in kilometers', code nodes 1, 2, and 3 run simultaneously ![Image](https://github.com/user-attachments/assets/c7ec0a05-c62c-4e06-b216-2f188574392e) - When the user inputs' How many kilometers does an electric car typically have', only code nodes 2, and 3 run simultaneously ![Image](https://github.com/user-attachments/assets/3497feda-de71-435b-8b35-41a124ce77bf) - When the user inputs' How many kilometers does a hydrogen powered vehicle typically have', only code nodes 3 run simultaneously ![Image](https://github.com/user-attachments/assets/68f9a50d-1eb4-45b6-bcc2-1e919ce67e4c)
yindo added the 🙏 help wanted🌊 feat:workflow labels 2026-02-21 19:10:14 -05:00
yindo closed this issue 2026-02-21 19:10:14 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Apr 16, 2025):

I found a similar open issue regarding parallel execution in workflows, where only the last configured node runs in parallel. This might be related to the configuration settings for parallel execution in the Dify codebase. Specifically, the IterationNode class has options like is_parallel and parallel_nums that determine parallel execution behavior. You might want to check these settings to ensure all nodes are configured to run in parallel as desired [1].

Additionally, to ensure multiple code nodes run simultaneously, you can use the Parallel Structure Design Pattern. Here are some methods to create a parallel structure:

  1. Hover over a node to reveal the + button and click it to add multiple nodes, forming a parallel structure.
  2. Extend a connection from a node by dragging its + button to create a parallel structure.
  3. Visually drag and link multiple nodes on the canvas to form a parallel structure.
  4. Add nodes through the "Next Step" section in a node's right-side panel, which automatically creates the parallel configuration [2].

To continue talking to Dosu, mention @dosu.


Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (Apr 16, 2025): <!-- Answer --> I found a similar open issue regarding parallel execution in workflows, where only the last configured node runs in parallel. This might be related to the configuration settings for parallel execution in the Dify codebase. Specifically, the `IterationNode` class has options like `is_parallel` and `parallel_nums` that determine parallel execution behavior. You might want to check these settings to ensure all nodes are configured to run in parallel as desired <sup>[[1]](https://github.com/langgenius/dify/issues/11528)</sup>. Additionally, to ensure multiple code nodes run simultaneously, you can use the Parallel Structure Design Pattern. Here are some methods to create a parallel structure: 1. Hover over a node to reveal the `+` button and click it to add multiple nodes, forming a parallel structure. 2. Extend a connection from a node by dragging its `+` button to create a parallel structure. 3. Visually drag and link multiple nodes on the canvas to form a parallel structure. 4. Add nodes through the "Next Step" section in a node's right-side panel, which automatically creates the parallel configuration <sup>[[2]](https://github.com/langgenius/dify-docs/blob/main/en/guides/workflow/orchestrate-node.md)</sup>. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/c6fe9c5c-b3f0-4e6b-a1b3-6f23ddd0b55c?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/c6fe9c5c-b3f0-4e6b-a1b3-6f23ddd0b55c?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/c6fe9c5c-b3f0-4e6b-a1b3-6f23ddd0b55c?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/c6fe9c5c-b3f0-4e6b-a1b3-6f23ddd0b55c?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c6fe9c5c-b3f0-4e6b-a1b3-6f23ddd0b55c?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/c6fe9c5c-b3f0-4e6b-a1b3-6f23ddd0b55c?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c6fe9c5c-b3f0-4e6b-a1b3-6f23ddd0b55c?feedback_type=other)</sup>
Author
Owner

@ACAne0320 commented on GitHub (Apr 21, 2025):

I think we should restrict nodes with multiple branches (e.g. problem classifiers, conditional branch IF/ELSE nodes) so that their different branches cannot connect to the same node.
Because in Graph's design, a node id, can only correspond to one parallel id,I think this is the key reason for this issue.
So a node can't have multiple incoming edges (i.e., it can't be connected by more than one branching node), just like the handling of knowledge retrieval nodes in this video.

https://github.com/user-attachments/assets/08861ff8-20ee-497a-86e1-ef2213feb478

What do you think?@crazywoola

@ACAne0320 commented on GitHub (Apr 21, 2025): I think we should restrict nodes with multiple branches (e.g. problem classifiers, conditional branch IF/ELSE nodes) so that their different branches cannot connect to the same node. Because in Graph's design, a node id, can only correspond to one parallel id,I think this is the key reason for this issue. So a node can't have multiple incoming edges (i.e., it can't be connected by more than one branching node), just like the handling of knowledge retrieval nodes in this video. https://github.com/user-attachments/assets/08861ff8-20ee-497a-86e1-ef2213feb478 What do you think?@crazywoola
Author
Owner

@Nov1c444 commented on GitHub (May 13, 2025):

I think we should restrict nodes with multiple branches (e.g. problem classifiers, conditional branch IF/ELSE nodes) so that their different branches cannot connect to the same node. Because in Graph's design, a node id, can only correspond to one parallel id,I think this is the key reason for this issue. So a node can't have multiple incoming edges (i.e., it can't be connected by more than one branching node), just like the handling of knowledge retrieval nodes in this video.

2025-04-21.14.29.41.mov
What do you think?@crazywoola

Your understanding is very correct, this question is identical to #15012.

@Nov1c444 commented on GitHub (May 13, 2025): > I think we should restrict nodes with multiple branches (e.g. problem classifiers, conditional branch IF/ELSE nodes) so that their different branches cannot connect to the same node. Because in Graph's design, a node id, can only correspond to one parallel id,I think this is the key reason for this issue. So a node can't have multiple incoming edges (i.e., it can't be connected by more than one branching node), just like the handling of knowledge retrieval nodes in this video. > > 2025-04-21.14.29.41.mov > What do you think?[@crazywoola](https://github.com/crazywoola) Your understanding is very correct, this question is identical to #15012.
Author
Owner

@ACAne0320 commented on GitHub (May 13, 2025):

I would be happy to submit this PR if restricting connections to nodes with multiple branches is a good idea.

@ACAne0320 commented on GitHub (May 13, 2025): I would be happy to submit this PR if restricting connections to nodes with multiple branches is a good idea.
Author
Owner

@Nov1c444 commented on GitHub (May 14, 2025):

I would be happy to submit this PR if restricting connections to nodes with multiple branches is a good idea.

I'm glad you could enthusiastically provide a solution. I need to discuss with my team colleagues whether this is a good solution. If possible, please wait for a while.

@Nov1c444 commented on GitHub (May 14, 2025): > I would be happy to submit this PR if restricting connections to nodes with multiple branches is a good idea. I'm glad you could enthusiastically provide a solution. I need to discuss with my team colleagues whether this is a good solution. If possible, please wait for a while.
Author
Owner

@ACAne0320 commented on GitHub (May 14, 2025):

I'm glad you could enthusiastically provide a solution. I need to discuss with my team colleagues whether this is a good solution. If possible, please wait for a while.

yep, a good solution needs more discussion, and I'm looking forward to your response.

@ACAne0320 commented on GitHub (May 14, 2025): > I'm glad you could enthusiastically provide a solution. I need to discuss with my team colleagues whether this is a good solution. If possible, please wait for a while. yep, a good solution needs more discussion, and I'm looking forward to your response.
Author
Owner

@jasonleelover commented on GitHub (May 14, 2025):

I think we should restrict nodes with multiple branches (e.g. problem classifiers, conditional branch IF/ELSE nodes) so that their different branches cannot connect to the same node. Because in Graph's design, a node id, can only correspond to one parallel id,I think this is the key reason for this issue. So a node can't have multiple incoming edges (i.e., it can't be connected by more than one branching node), just like the handling of knowledge retrieval nodes in this video.

2025-04-21.14.29.41.mov
What do you think?@crazywoola

This approach is only to avoid this problem, not to solve it. The reason why developers encounter this problem is because they want to reuse nodes. If they can solve this problem by reusing nodes in parallel lines, this issue can be resolved. @Nov1c444

@jasonleelover commented on GitHub (May 14, 2025): > I think we should restrict nodes with multiple branches (e.g. problem classifiers, conditional branch IF/ELSE nodes) so that their different branches cannot connect to the same node. Because in Graph's design, a node id, can only correspond to one parallel id,I think this is the key reason for this issue. So a node can't have multiple incoming edges (i.e., it can't be connected by more than one branching node), just like the handling of knowledge retrieval nodes in this video. > > 2025-04-21.14.29.41.mov > What do you think?[@crazywoola](https://github.com/crazywoola) This approach is only to avoid this problem, not to solve it. The reason why developers encounter this problem is because they want to reuse nodes. If they can solve this problem by reusing nodes in parallel lines, this issue can be resolved. @Nov1c444
Author
Owner

@ACAne0320 commented on GitHub (May 16, 2025):

This approach is only to avoid this problem, not to solve it.

I don't think I'm avoiding the problem. The problem arises because the design of the graph engine doesn't support connecting a node to multiple parallel branches.
When using the outputs of the problem classification node to connect to other nodes, the multiple outputs are treated as the same node. Therefore, you can connect multiple parallel branches.

That's the key to your problem.

If you use an intermediate node to connect to subsequent nodes after each classification, you'll notice that it's not possible to join multiple parallel branches. (As shown in the video above.)

If they can solve this problem by reusing nodes in parallel lines, this issue can be resolved.

If we need to reuse nodes in parallel branches, I think this feature should be listed as a new feature, not a bug.

Of course, it's ultimately up to the Dify team to decide.

@ACAne0320 commented on GitHub (May 16, 2025): > This approach is only to avoid this problem, not to solve it. I don't think I'm avoiding the problem. The problem arises because the design of the graph engine doesn't support connecting a node to multiple parallel branches. When using the outputs of the problem classification node to connect to other nodes, the multiple outputs are treated as the same node. Therefore, you can connect multiple parallel branches. That's the **key** to your problem. If you use an intermediate node to connect to subsequent nodes after each classification, you'll notice that it's not possible to join multiple parallel branches. (As shown in the video above.) > If they can solve this problem by reusing nodes in parallel lines, this issue can be resolved. If we need to reuse nodes in parallel branches, I think this feature should be listed as a new feature, not a bug. Of course, it's ultimately up to the Dify team to decide.
Author
Owner

@dosubot[bot] commented on GitHub (Sep 1, 2025):

Hi, @jasonleelover. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported that in version 1.2.0 (Docker self-hosted), multiple code nodes intended to run in parallel sometimes fail, resulting in fewer nodes running than expected.
  • Discussion highlighted a core limitation where a node ID can only correspond to one parallel ID, causing issues with nodes having multiple incoming edges.
  • A proposed PR aims to restrict connections to such nodes to avoid the problem, but you pointed out this is a workaround rather than a true fix.
  • You advocate for enabling node reuse in parallel branches to properly solve the issue.
  • The maintainers are still deliberating on the best approach to address this limitation.

Next Steps:

  • Please let me know if this issue is still relevant with the latest version of Dify by commenting here to keep the discussion open.
  • Otherwise, this issue will be automatically closed in 15 days.

Thanks for your understanding and contribution!

@dosubot[bot] commented on GitHub (Sep 1, 2025): Hi, @jasonleelover. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported that in version 1.2.0 (Docker self-hosted), multiple code nodes intended to run in parallel sometimes fail, resulting in fewer nodes running than expected. - Discussion highlighted a core limitation where a node ID can only correspond to one parallel ID, causing issues with nodes having multiple incoming edges. - A proposed PR aims to restrict connections to such nodes to avoid the problem, but you pointed out this is a workaround rather than a true fix. - You advocate for enabling node reuse in parallel branches to properly solve the issue. - The maintainers are still deliberating on the best approach to address this limitation. **Next Steps:** - Please let me know if this issue is still relevant with the latest version of Dify by commenting here to keep the discussion open. - Otherwise, this issue will be automatically closed in 15 days. Thanks for your understanding and contribution!
Author
Owner

@jasonleelover commented on GitHub (Sep 1, 2025):

Hi, @jasonleelover. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported that in version 1.2.0 (Docker self-hosted), multiple code nodes intended to run in parallel sometimes fail, resulting in fewer nodes running than expected.
  • Discussion highlighted a core limitation where a node ID can only correspond to one parallel ID, causing issues with nodes having multiple incoming edges.
  • A proposed PR aims to restrict connections to such nodes to avoid the problem, but you pointed out this is a workaround rather than a true fix.
  • You advocate for enabling node reuse in parallel branches to properly solve the issue.
  • The maintainers are still deliberating on the best approach to address this limitation.

Next Steps:

  • Please let me know if this issue is still relevant with the latest version of Dify by commenting here to keep the discussion open.
  • Otherwise, this issue will be automatically closed in 15 days.

Thanks for your understanding and contribution!

I tried using Hosted (Docker) version 1.8.0 and the issue still persists
parallel_running_of_nodes_test.yml

@jasonleelover commented on GitHub (Sep 1, 2025): > Hi, [@jasonleelover](https://github.com/jasonleelover). I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. > > **Issue Summary:** > > * You reported that in version 1.2.0 (Docker self-hosted), multiple code nodes intended to run in parallel sometimes fail, resulting in fewer nodes running than expected. > * Discussion highlighted a core limitation where a node ID can only correspond to one parallel ID, causing issues with nodes having multiple incoming edges. > * A proposed PR aims to restrict connections to such nodes to avoid the problem, but you pointed out this is a workaround rather than a true fix. > * You advocate for enabling node reuse in parallel branches to properly solve the issue. > * The maintainers are still deliberating on the best approach to address this limitation. > > **Next Steps:** > > * Please let me know if this issue is still relevant with the latest version of Dify by commenting here to keep the discussion open. > * Otherwise, this issue will be automatically closed in 15 days. > > Thanks for your understanding and contribution! I tried using Hosted (Docker) version 1.8.0 and the issue still persists [parallel_running_of_nodes_test.yml](https://github.com/user-attachments/files/22085231/parallel_running_of_nodes_test.yml)
Author
Owner

@ACAne0320 commented on GitHub (Sep 1, 2025):

Maybe you can take a look at this PR #24068

@ACAne0320 commented on GitHub (Sep 1, 2025): Maybe you can take a look at this PR #24068
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#13029