Difyコミュニティ、スケジュールの重複実行を報告　並行公開で重複トリガーが作成される可能性

Difyコミュニティは10月28日、スケジュールの整合性に関する問題を報告した。Scheduleトリガーを含むワークフローを2つのリクエストが同時に公開すると、同じノードに対して有効なトリガーレコードが複数作成される可能性がある。報告ではセルフホスト環境のmainブランチを対象に、コミットバージョンと再現手順が示されている。現時点では確認待ちのバグ報告として扱うべきであり、すべての本番リリースに影響するとまでは判断できない。問題報告

報告者の分析によると、公開処理は「先に検索し、その後に追加する」方式を採っている。2つのトランザクションが同時に既存レコードを見つけられず、それぞれ書き込む可能性がある。app_triggersには(app_id, node_id)に対する一意制約がない。スケジュールポーラーがこの2つのカラムでトリガーデータを結合すると、同じスケジュール計画が複数のディスパッチに展開される可能性がある。この挙動が確認されれば、モデル呼び出しや外部ツール操作が重複して実行されるおそれがある。再現条件と原因分析

報告では、結合クエリをEXISTS条件に置き換え、重複トリガーによって結果行数が増えないようにしつつ、FOR UPDATE SKIP LOCKEDを維持する案が提示された。この選択の背景にはデータベースの制約がある。PostgreSQLではDISTINCTと行ロック句を同時に使用できない。一方、SKIP LOCKEDは別のトランザクションがロック中の行をスキップするため、複数のコンシューマーがキューを処理する場合に適している。単純に重複排除キーワードを追加するだけでは、既存のロック方式をそのまま維持できない。PostgreSQL SELECTドキュメント

クエリで重複を排除すればディスパッチ結果は抑えられるが、重複データが生じる原因への対処も必要だ。報告では、今後の対応として一意制約の追加、既存の重複レコードの削除、公開時の書き込みの冪等化も提案されている。デプロイ担当チームは、同じアプリとノードに対するトリガー件数および実行ログをまず照合できる。今後は、メンテナーが再現できるか、修正にデータ移行が含まれるか、本番リリースにいつ反映されるかを追跡する必要がある。今回の確認時点では修正提案の内容を取得できなかったため、問題が修正済みだとは言えない。修正提案と今後の推奨事項