Difyコミュニティがトリガー分離の修正を提案、未公開のドラフトが本番ワークフローのイベントを中断する可能性

Difyにおけるドラフトと本番ワークフローの分離について、新たな懸念が浮上しました。10月14日、あるユーザーが、バージョン1.17.1と表示されたCloud環境で、未公開のドラフトが公開済みのIntegration Triggerワークフローに影響すると報告しました。サブスクリプションの解除、トリガーノードの削除、またはエクスポートした設定の同じアプリへの再インポートによって、本番ワークフローがイベントを受信しなくなる可能性があります。公開された事例ではGitHub Starイベントを使って再現されていますが、すべての統合で同じ結果になるとは限りません。問題報告

この挙動は、公開境界に対するユーザーの想定に反します。Difyの公式チュートリアルでは、変更を反映するには再度公開する必要があると説明されています。そのため、ドラフトを保存しただけで本番イベントの入口が変わるなら、エンジニアが次のワークフロー版を調整する際に、既存の自動化サービスまで妨げるおそれがあります。公式の公開に関する説明

報告で重要なのは、「実行記録が残らない」という現象です。テスターはまず、Starイベントでワークフローが起動することを確認してから、ドラフトのサブスクリプションを削除しました。その後のイベントについては、成功・失敗いずれの実行記録も作成されませんでした。公開せずにドラフトでサブスクリプションを再選択すると、本番ワークフローは復旧しました。このことから、調査の焦点は下流のモデルノードではなく、イベントとワークフローの紐付けにあります。再現手順

同日に提出された修正PR #44068は、トリガーの登録を公開専用のシグナルに紐付け、ドラフトの同期中も本番ワークフローで使用中のトリガーを維持するものです。作成者によると、対象を絞った2件の回帰テストは修正前に失敗し、修正後に通過しました。また、Ruff、フォーマット、差分の各チェックも完了しています。確認時点で提案はまだレビュー中であり、正式リリースで修正済みとはみなせません。修正提案と検証

運用チームにとって、この事例はワークフローの失敗率だけを監視していると、実行自体が作成されなかったイベントを見逃す可能性を示しています。上記の現象を踏まえると、テスト環境でドラフト変更の前後におけるイベント受信数と実行数を比較し、設定のインポート経路も別途テストするのが有効です。今後は、メンテナーが根本原因を確認するか、修正がマージされるか、正式リリース前にほかのIntegration Triggerのテストが追加されるかを追う必要があります。現時点の2件の回帰テストだけでは、Cloudのイベント処理経路全体が復旧したと証明するには不十分です。