Difyコミュニティがエージェントのストリーミング遅延を報告、失敗分岐の有効化でタスク終了までテキスト送信が遅れる可能性

Difyコミュニティは10月12日、ストリーミング動作に関する報告を追加した。セルフホスト版1.17.1のChatflowで、Agentノードのエラー処理に「Fail Branch」を有効にすると、モデルがテキストを生成し続けていても、ノードの実行が終わるまでクライアントに回答が届かない場合があるという。事例ではagent 0.0.33プラグインとFunction Calling戦略を使い、互換ゲートウェイ経由でvLLM／Qwen3に接続している。報告と再現手順

報告者は、同じモデルとプロンプトで設定を切り替えて比較した。失敗分岐を有効にした場合、805件のテキストイベントは約29.8秒後に届き始め、0.216秒以内にまとめて送信された。デフォルトのエラー処理を使った比較対象では、約3.4秒後に出力が始まった。2回の生成では出力の長さと所要時間が異なるため、この数値を一般的な性能ベンチマークとして扱うことはできないが、ストリーミング遅延の原因を特定する具体的な手がかりにはなる。同じリクエストのエージェントログは引き続きリアルタイムで届いており、テキストとログでは出力条件が異なる可能性も示されている。イベント計測

報告者は原因としてgraphon 0.7.0を挙げている。失敗分岐の設定によってノードが分岐実行タイプに分類され、ストリーミングフィルターがその出力エッジをブロッキングエッジとして扱うため、分岐が確定するまでバッファー内の内容が送信されない、という分析だ。ただし、これは投稿者による見立てである。公式ドキュメントでは、Answerノードは変数が利用可能になるのに応じて段階的に出力し、未解決の変数があると待機すると説明されている。そのため、エンジニアリング上はモデル側とワークフロー側の両方で、どの条件が待機を引き起こしているかを調べる必要がある。コードパス分析、Answerのストリーミングに関するドキュメント

この報告が注目されるのは、失敗分岐が本来、エラー通知、代替サービス、復旧フローに使われる機能でありながら、通常の回答で体感する遅延にも影響する可能性があるためだ。デフォルト設定に戻せば分岐による復旧機能を失うため、ストリーミングを回復させる目的だけで安易に切り替えることはできない。デプロイ担当者はまずテキストとログのイベント時刻を記録し、設定の違いによる再現を試みたうえで、メンテナーが問題を確認するか、また後続の修正が失敗時のルーティングと段階的な出力を両立できるかを追跡できる。確認時点でこのIssueはオープンのままで、修正PRへのリンクはない。ほかのバージョンやクラウドサービスへの影響も、まだ検証されていない。エラー処理のドキュメント、Issueの状態