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

并行节点LLM Stream回复节点格式错乱 #7647

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

Originally created by @CrankGentleman on GitHub (Jan 10, 2025).

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

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

添加多个并行节点，同时带有迭代任务，预览输出内容错乱
输入：搜索一下西红柿炒鸡蛋的食谱，写一篇关于先有鸡还是先有蛋的论文

此时两个需求任务同时执行，论文的LLM回复还未执行完，此时食谱的执行完了，会在论文中直接插入，导致了整体回复格式错乱
1
2
3

✔️ Expected Behavior

同时并行执行，我查看task_id都是相同的，导致了具体节点执行的中还是执行完成并不能准确捕获，所以无法归整成按照需求节点进行task_id的分类。

希望每一个子需求节点输出单独有一个唯一的id，直到当前此子节点完成。用一个唯一的标识进行归类，这样在处理多需求子节点执行时，正确的处理好message的辨别。

api调用和使用dify的工作台预览都支持并且修复回复的错误问题

❌ Actual Behavior

No response

Originally created by @CrankGentleman on GitHub (Jan 10, 2025). ### 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.15.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 添加多个并行节点，同时带有迭代任务，预览输出内容错乱 输入：搜索一下西红柿炒鸡蛋的食谱，写一篇关于先有鸡还是先有蛋的论文 此时两个需求任务同时执行，论文的LLM回复还未执行完，此时食谱的执行完了，会在论文中直接插入，导致了整体回复格式错乱 ![1](https://github.com/user-attachments/assets/c6a72036-1dc4-445f-aece-daa3b3cb40a3) ![2](https://github.com/user-attachments/assets/033776af-a46a-4708-aac0-07f7a0e9ad5b) ![3](https://github.com/user-attachments/assets/ddbd0c64-8479-4f96-846c-72c55bcd4729) ### ✔️ Expected Behavior 同时并行执行，我查看task_id都是相同的，导致了具体节点执行的中还是执行完成并不能准确捕获，所以无法归整成按照需求节点进行task_id的分类。 希望每一个子需求节点输出单独有一个唯一的id，直到当前此子节点完成。用一个唯一的标识进行归类，这样在处理多需求子节点执行时，正确的处理好message的辨别。 api调用和使用dify的工作台预览都支持并且修复回复的错误问题 ### ❌ Actual Behavior _No response_
yindo added the 🌊 feat:workflow label 2026-02-21 18:21:38 -05:00
yindo closed this issue 2026-02-21 18:21:38 -05:00
yindo commented 2026-02-21 18:21:38 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 10, 2025):

The issue you're experiencing seems to be related to the handling of task_id in parallel node execution within Dify. When multiple tasks are executed in parallel, they currently share the same task_id, which leads to confusion and incorrect message formatting as the outputs from different tasks get mixed up.

To address this, it would be beneficial for each sub-task node to have a unique identifier (task_id) that remains consistent until the task is completed. This would allow for proper categorization and separation of messages, ensuring that each task's output is correctly identified and formatted.

Unfortunately, I couldn't find specific information on how Dify currently handles unique identification for sub-task nodes or any existing mechanisms to resolve message response conflicts in parallel execution scenarios. It might be necessary to implement a feature that assigns unique task_ids to each sub-task to prevent such issues.

If this is a critical issue affecting your workflow, you might consider proposing a feature request or checking if there are any updates or plugins that address this problem in the Dify community or documentation.

To continue talking to Dosu, mention @dosu.

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

@dosubot[bot] commented on GitHub (Jan 10, 2025): <!-- Answer --> The issue you're experiencing seems to be related to the handling of `task_id` in parallel node execution within Dify. When multiple tasks are executed in parallel, they currently share the same `task_id`, which leads to confusion and incorrect message formatting as the outputs from different tasks get mixed up. To address this, it would be beneficial for each sub-task node to have a unique identifier (`task_id`) that remains consistent until the task is completed. This would allow for proper categorization and separation of messages, ensuring that each task's output is correctly identified and formatted. Unfortunately, I couldn't find specific information on how Dify currently handles unique identification for sub-task nodes or any existing mechanisms to resolve message response conflicts in parallel execution scenarios. It might be necessary to implement a feature that assigns unique `task_ids` to each sub-task to prevent such issues. If this is a critical issue affecting your workflow, you might consider proposing a feature request or checking if there are any updates or plugins that address this problem in the Dify community or documentation. <!-- 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/7dfe10f8-1bea-45f0-bfcb-8ac65a02a58b?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/7dfe10f8-1bea-45f0-bfcb-8ac65a02a58b?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/7dfe10f8-1bea-45f0-bfcb-8ac65a02a58b?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/7dfe10f8-1bea-45f0-bfcb-8ac65a02a58b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/7dfe10f8-1bea-45f0-bfcb-8ac65a02a58b?feedback_type=hallucination) | [Other](https://app.dosu.dev/response-feedback/7dfe10f8-1bea-45f0-bfcb-8ac65a02a58b?feedback_type=other)</sup>
yindo commented 2026-02-21 18:21:38 -05:00
Author
Owner
Copy Link
Copy Source

@CrankGentleman commented on GitHub (Jan 10, 2025):

不是迭代节点，是并行执行的，同时存在多个回复，就会出现错误的问题。每个node_start的时候增加一个属于自己的id，同时整个子链路执行id携带且不变，如果使用dify的网页运行和编辑预览模式下，都加入id和message的绑定回复，就不会出现排版错乱的问题，使用api调用的话，开发人员可以自行去判断。

当然这只不过是我提供的实现思路，仅供参考

@CrankGentleman commented on GitHub (Jan 10, 2025): 不是迭代节点，是并行执行的，同时存在多个回复，就会出现错误的问题。每个node_start的时候增加一个属于自己的id，同时整个子链路执行id携带且不变，如果使用dify的网页运行和编辑预览模式下，都加入id和message的绑定回复，就不会出现排版错乱的问题，使用api调用的话，开发人员可以自行去判断。 当然这只不过是我提供的实现思路，仅供参考
yindo commented 2026-02-21 18:21:38 -05:00
Author
Owner
Copy Link
Copy Source

@CrankGentleman commented on GitHub (Jan 12, 2025):

@crazywoola 想请问一下closed的原因，是当前版本已经有地方可以支持，还是说在后续的版本加入，目前我所用到的，多节点回复确实没有办法区分，导致各个节点的回复无法拆分，因为每一个回复节点，我使用api调用，无法用一个特有的标识来合并message的event

@CrankGentleman commented on GitHub (Jan 12, 2025): @crazywoola 想请问一下closed的原因，是当前版本已经有地方可以支持，还是说在后续的版本加入，目前我所用到的，多节点回复确实没有办法区分，导致各个节点的回复无法拆分，因为每一个回复节点，我使用api调用，无法用一个特有的标识来合并message的event
yindo commented 2026-02-21 18:21:38 -05:00
Author
Owner
Copy Link
Copy Source

@yihong0618 commented on GitHub (Jan 12, 2025):

[FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）

@yihong0618 commented on GitHub (Jan 12, 2025): > [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
yindo commented 2026-02-21 18:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@CrankGentleman commented on GitHub (Jan 12, 2025):

okok，我的问题

@CrankGentleman commented on GitHub (Jan 12, 2025): okok，我的问题
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 🌊 feat:workflow
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#7647
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?