Dify Community Reports Agent Streaming Delay; Enabling Fail Branch May Hold Text Until Task Ends

On October 12, the Dify community reported a streaming behavior in a self-hosted 1.17.1 Chatflow: when an Agent node has “Fail Branch” error handling enabled, the client may not receive an answer until the node finishes, even while the model continues generating text. The case used the agent 0.0.33 plugin, the Function Calling strategy, and vLLM/Qwen3 connected through a compatible gateway. Report and reproduction steps

The reporter compared settings with the same model and prompt. With Fail Branch enabled, about 805 text events began arriving at around 29.8 seconds and were delivered in a burst over 0.216 seconds. In the comparison using default error handling, output began at around 3.4 seconds. The generations differed in length and total duration, so these figures are not a general performance benchmark, but they offer concrete clues for investigating the streaming delay. Agent logs for the same request still arrived in real time, suggesting that text and logs may have different release conditions. Event measurements

The report points to graphon 0.7.0 as the cause: the Fail Branch setting changes the node’s execution type to a branch execution type, and the streaming filter then treats its output edge as a blocking edge, waiting for the branch to be determined before releasing buffered content. This remains the submitter’s analysis. Official documentation also explains that an Answer node streams output as variables become available and waits when it encounters an unresolved variable. Engineers therefore need to check waiting conditions on both the model side and the workflow side. Code path analysis, Answer streaming documentation

The report matters because Fail Branch is intended for error notifications, fallback services, and recovery flows, yet may affect the perceived latency of normal responses. Temporarily switching back to the default setting would sacrifice branch-based recovery, so it should not be applied solely to restore streaming. Deployment teams can first record text and log event timings, reproduce the configuration difference, and then track whether maintainers confirm the issue and whether a future fix can preserve both failure routing and incremental output. As of this review, the issue remains open and is not linked to a fix PR; impact on other versions and the cloud service has yet to be verified. Error handling documentation, Issue status