When using parallelism, it may unexpectedly cause streaming output to fail.

[Reverse-Flash-Kamen]

Self Checks

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

Dify version

1.4.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

https://github.com/user-attachments/assets/1bb68dd2-b9a6-4fd2-9d99-c4dbd5d7cf0a https://github.com/user-attachments/assets/c1387f36-6eb5-4b70-bec0-253d6c5db6a1

Here is my DSL file

noStreaming.txt

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

[Reverse-Flash-Kamen]

Even after adding a variable aggregation node, the streaming output still cannot be used normally.

[dosubot[bot]]

In Dify version 1.4.0, there are known limitations with parallelism that might affect streaming output. Specifically, when using parallelism, the same nodes cannot run in parallel across different conditional branches, and each node can only have one parallel ID ^[1]. Additionally, the variable aggregation node does not support streaming output, which is a design choice in Dify ^[2].

To address the issue with streaming output failing due to parallelism, consider the following:

1. Separate Nodes for Parallel Execution: Ensure that you are not reusing the same nodes across different branches. Create separate, duplicate nodes for each parallel execution path.

2. Nginx Configuration: If you are running Dify in a self-hosted Docker environment, check your Nginx configuration. The default setup might cache messages, leading to blocking output. Modify your Nginx configuration to support Server-Sent Events (SSE) to enable proper streaming output ^[3].

3. Variable Aggregation Node: Since the variable aggregation node does not support streaming output, avoid using it if streaming is required in your workflow ^[2].

These steps should help mitigate the issues with streaming output when using parallelism in your Dify setup.

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}

[Reverse-Flash-Kamen]

So, does that mean I have to give up streaming output if I want to use parallelism in the workflow? @dosu

[dosubot[bot]]

No, you do not have to give up streaming output if you want to use parallelism in the workflow. The streaming output issue in complex Dify workflows can be resolved by applying the patch from PR #12355, which addresses the problem of streaming output switching to blocking mode when using 'if else' nodes in combination with answer nodes. A simple workflow without these nodes maintains normal streaming output ^[1].

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}

[Reverse-Flash-Kamen]

It's not that using if-else nodes causes the streaming output to switch to blocking mode. Now, as long as I use parallelism, this issue will be reproduced. @dosu

[dosubot[bot]]

To resolve streaming output issues when using parallelism in Dify version 1.4.0, you can try wrapping the problematic nodes (such as LLM and response components) in a loop component that iterates only once. This configuration has been confirmed to restore normal streaming output functionality ^[1].

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}

[Reverse-Flash-Kamen]

I merged complex parallel operations into the workflow and called the workflow in Chatflow, which allows normal use of streaming output. I found that the current version supports passing parameters to workflows—thanks for the update! However, I still wonder how to use both parallel operations and streaming output in Chatflow.

[Reverse-Flash-Kamen]

My new problem is with the Variable Aggregator node – if you want to use streaming output, you must not use this node in Chatflow.