DifyコミュニティがNode.js SDKのストリーミング修正を提案、置換イベント後も元の文章が残る可能性

Difyコミュニティは10月15日、Node.js SDKのストリーミング収集に関する不具合を報告しました。対象はdify-client 3.1.0と、報告に記載されたメインブランチのバージョンです。応答をまとめるstream.toText()は、ワークフローがすでにテキストを出力していても空文字列を返す場合があります。また、コンテンツ審査による置換イベントを受け取ると、置き換えられるはずの元の回答が残る可能性があります。別の貢献者も16日、この2つの挙動を再現したと報告しました。報告と再現手順

原因はイベントの意味とフィールドの位置にあります。既存の収集処理はトップレベルのanswer、text、deltaを読み取りますが、ワークフローのtext_chunkではテキストがdata.textに格納されているため、無視されます。一方、message_replaceには置換後の完全な回答が含まれます。追加方式のまま処理すると、最終的な文字列に元の内容と審査後の回答の両方が含まれてしまいます。報告には、サーバーを起動せずに収集処理の挙動を直接確認できる、合成SSEテストも示されています。技術的な詳細

同日に提案された修正では、text_chunkからネストされたテキストを読み取り、message_replaceで蓄積済みの内容を上書きします。推論テキストが回答に混入しないよう、その他のネストされたイベントは引き続き無視します。提案者によると、回帰テストを2件追加し、SDK全体のテスト139件、型チェック、フォーマットチェックがすべて通過しました。現在、提案はオープンのままで、コードオーナーのレビュー待ちです。修正提案

自前のチャットインターフェースやエージェントのバックエンドを構築するチームには、直接関係する問題です。報告された挙動から推測すると、サービス側が審査による置換メッセージを送っても、下流の処理が集約結果を保存したり別のツールに渡したりする際に、元の文章が使われ続ける可能性があります。Difyの公式ドキュメントも、イベントの種類に応じて処理を振り分け、テキストチャンク、完了イベント、エラーイベントを区別するよう求めています。これは、ストリーミング連携では応答の状態管理が必要であることを示しています。公式ストリーミングガイド

エンジニアリングチームは、ネストされたテキスト、置換後の回答、最終的な保存結果を含む固定のイベント列を使い、自社のSDKやラッパー層の挙動を確認できます。今後は修正のマージとパッケージのリリースを追跡する必要があります。現時点の証拠が示しているのは、特定の収集関数に問題があるということです。すべてのDifyクライアントやデプロイ環境が影響を受けると結論づけるには、まだ十分ではありません。