Difyコミュニティ、停止後もキュー内ノードが起動すると報告　キャンセル指示が後続のツール呼び出しを阻止できない可能性

Difyのワークフロー停止機構について、新たにキュー処理の問題が報告された。貢献者は10月20日、セルフホスト環境のメインブランチ ac17912 で、フローの中断状態またはRedisの停止フラグが設定済みでも、ワーカーが以前にキューに入ったノードを取得して実行を開始する場合があると指摘した。これにより、キャンセル操作の実効範囲がモデルやツール呼び出しに伴うコストと副作用にまで及ぶ可能性がある。問題報告

報告では、問題の原因を StopAwareReadyQueue に特定している。現在、タスクを追加する put() の処理経路では停止条件を確認する一方、タスクを取り出す get() は内側のキューにそのまま処理を委ねている。そのため、停止シグナルは新しいタスクの追加を阻止できても、すでにキューで待機中のタスクまでは止められない。再現手順は、まず StartTask をキューに入れ、その後、中断済みのフロー状態でタスクを取得するというものだ。報告者によると、この場合でもシステムはタスクを返す。並列ブランチと単一ワーカーの組み合わせが、この状況が起こり得る例として挙げられている。再現手順

同日に提出された修正案は、タスクの取得時に停止状態を確認し、実行待ちのタスクを完了扱いにして queue.Empty を送出することで、ワーカーがキュー内のノードを起動しないようにする。すでに実行中のノードは、引き続き完了する可能性がある。作者によると、追加した回帰テストは元のメインブランチでは失敗し、修正を適用すると関連テスト69件がすべて通過した。これは具体的な検証材料だが、提案はまだ審査待ちで公開中のため、正式リリース版ですでに修正済みとは言えない。修正提案と検証の説明

API連携を行う開発者向けに、公式ドキュメントでは、今回の生成を制御する task_id と、永続化された実行記録を追跡する workflow_run_id を区別しており、停止エンドポイントでは前者を使う。この問題の仕組みから推測すると、エンジニアリングチームがキャンセル動作を検証する際は、ノードの開始時刻、ツール側へのリクエスト、実行記録をあわせて確認し、停止後に新たな操作が発生していないかを確かめる必要がある。特に外部システムへの書き込みを行うフローでは、キューに入ったブランチのキャンセル境界をテストすべきだ。公式ストリーミングガイド

現時点の根拠は、コミュニティによるメインブランチでの再現と修正テストに限られる。保守担当者による影響範囲全体の確認はまだなく、クラウドサービスでの事故や実損を示す証拠もない。今後は提案の審査とマージの状況、そしてどの正式版に修正が含まれるかを追う必要がある。