ワークフローが1つあり、2つのタイマートリガーがあります。そのうちの1つは毎日設定された時間にトリガーされますが、もう1つはトリガーされません。手動テストでは問題ありません。ログでも、毎日1つのトリガーのみがトリガーされていることが確認できます。
現在、Difyは同じワークフローで「複数のトリガーの並行実行」をサポートしていますか?
ありがとうございます。
現在、Difyのワークフローにおける「定期トリガー」は、設計上、1つのワークフローに複数のトリガーを配置することをサポートしていますが、いくつかの落とし穴があり、ご説明の現象(1つは時間通りにトリガーされるが、もう1つは手動テストでは成功するものの、計画通りには実行されない)を引き起こす可能性があります。
まず結論から申し上げます。
- 概念的には「1つのワークフローで複数のトリガーが並行して実行される」ことをサポートしています。
- しかし、現在のバージョンでは、定期トリガーに関して、いくつかの制限/バグ、または設定の詳細に問題がある可能性があり、実際の効果は「1つしか実行されない」ことが多いです。以下に、いくつかのトラブルシューティングの方向性と、確実な推奨ソリューションを提示します。
一、まず確認すべきいくつかの重要な点
以下の項目を一つずつ確認してください。
-
2つの定期トリガーの有効化状態
- 両方とも「無効」になっていませんか?インターフェースには通常、enable/disableまたはスイッチがあります。
- ノードをコピーした後、新しい定期トリガーがデフォルトでオフまたは未保存になっている場合があります。
-
時間設定が競合/重複していないか
- 例えば:
- 一方が「毎日10:00」、もう一方も「毎日10:00」または非常に近い時間である場合。
- スケジューリングの実装によっては、同じワークフローの同じ時刻における複数の計画を「マージ」したり、「1つだけ保持」したりするものがあります。
- まずテストとして、2つ目のトリガーを完全に異なる時間(例:1つは10:00、もう1つは10:05)に変更し、2つ目が正常に実行されるか確認することをお勧めします。
- 例えば:
-
タイムゾーンの問題
- Difyの定期タスクはどのタイムゾーンで実行されますか?
- サーバー/Difyの設定がAsia/Shanghaiではなく、インターフェースで現地時間として理解している場合、実際にはすでにトリガーされているのに、時間を見間違えている可能性があります。
- 比較してください:
- 定期トリガーの設定時間
- ログに記録されたトリガー時間
8時間/数時間のずれがないか確認してください。
-
トリガーログで2つのトリガーを区別できるか
- 通常、各トリガーノードには独自のID/名前があります。ログで「毎日1つだけトリガーされている」と表示される場合:
- 実際に1つのノードの記録しか見えないのか、それとも2つのノードが実行されたが、その後のプロセスがマージされたのか?
- もし区別できるのであれば、これら2つの定期トリガーに明確に異なる名前を付けて、ログで検索しやすくしてください。
- 通常、各トリガーノードには独自のID/名前があります。ログで「毎日1つだけトリガーされている」と表示される場合:
-
同じ「入口」下流ノードを使用しているか
- 例えば、2つの定期トリガーが同じ下流ノードに接続されており、このノードまたは後続のノードに何らかの「排他」ロジック(例:シングルタスク、ロック、レート制限)がある場合、1つだけが実行されているように見えることがあります。
二、現在存在する可能性のある設計上の制限/実装の詳細
一部のバージョン/実装では、スケジューラーが「同じワークフローの複数のスケジュール」に対して、以下のいずれかの状況になる可能性があります。
- 同じアプリ/ワークフローに「単一のスケジュールをバインド」し、最初の設定のみが有効になる。
- または、スケジューラーサービスにバグがあり、複数のcronのうち1つしか有効にならない。
- あるいは、最大同時実行タスク数、再入防止の制限がある:
- 例えば、ある時点でワークフローがすでに実行中の場合、スケジューラーは新しいトリガーをスキップし、同じワークフローの再入を防ぎます。
- 最初のトリガーの実行時間が長い場合、同じ時間枠でトリガーされた2番目のトリガーはスキップされます。
現在、バージョンに対応するソースコードやissueリストを直接確認できないため、一般的なワークフロースケジューリングの実装に基づいて推測するしかありません。
確実を期すため、現時点では次のように理解してください:設計目標は複数の定期トリガーをサポートすることですが、特定のバージョン/シナリオでは動作が完全に安定しない、または1つしか有効にならない場合があります。
三、推奨される安定したソリューション
これらの実装の詳細に悩まされないために、実践的により確実な2つのソリューションを提案します。
ソリューションA:2つのワークフローに分割し、それぞれに1つの定期トリガーを設定する
- 現在のワークフローロジックを次のように分割します。
- ワークフローA:「定期トリガーA + 対応する分岐ロジック」のみを保持します。
- ワークフローB:「定期トリガーB + 対応する分岐ロジック」のみを保持します。
- それぞれ個別に定期タスクを設定します。
- これにより、スケジューリング上は完全に独立した2つの計画タスクとなり、互いに影響しません。
利点:
- 最も直感的で、落とし穴が少ないです。
- ログと問題のトラブルシューティングが非常に明確です。どれが実行されなかったか一目でわかります。
- 「同じワークフローの複数のスケジューラー」の現在のバージョン固有の実装に依存しません。
ソリューションB:1つの定期トリガーを保持し、「ルーティング/条件ノード」で内部的に区別する
- ワークフローの入口に1つの「定期トリガー」のみを保持します。
- 定期トリガーの後、「条件判断/Routerノード」を接続します。
- ここで「現在の時間/日付/カスタム変数」に基づいて、どちらのパスに進むかを判断します。
- 例えば:
- 毎日10:00に1回トリガー
- ワークフロー内で判断:今日が平日であれば → パス1に進む。そうでなければ → パス2に進む。
- または、日付を2で割った余り、7で割った余り、曜日などの条件で分岐します。
- 例えば:
- ここで「現在の時間/日付/カスタム変数」に基づいて、どちらのパスに進むかを判断します。
- 毎日固定の2つの異なる時間帯に2つのロジックを実行したい場合は、次のようにできます。
- 1つの定期トリガーの頻度を少し高く設定します(例えば30分ごとに実行しますが、内部条件で10:00±数分のウィンドウを満たす場合のみ「ロジックA」を実行し、15:00±数分のウィンドウを満たす場合のみ「ロジックB」を実行し、それ以外の時間分岐は直接終了します)。
利点:
- 「複数の定期トリガー」自体のスケジューリング互換性の問題を完全に回避します。
- すべてのロジックが1つのワークフローに集中しているため、メンテナンスと全体の状態の確認が容易です。
四、確認/補足していただきたい情報
もし引き続きトラブルシューティングにご協力いただけるのであれば、以下の情報をご提供いただけると、より具体的に原因を推測できます。
- Difyのバージョン番号(設定ページまたはdocker-composeでイメージタグを確認できます)。
- 2つの定期トリガーの具体的な設定方法(例:
- トリガー1:毎日10:00
- トリガー2:毎日18:00
タイムゾーンの設定はどうなっていますか?
- ログに2番目のトリガーノードの実行記録が何か見られますか(ノード名/IDのスクリーンショットまたはテキスト説明で構いません)。
- 2つのトリガーの下流は一部のノードを共有していますか、それとも完全に独立した2つの経路ですか?
まとめ
- 理論上:Difyは「同じワークフローに複数のトリガーが存在する」ことをサポートしています。
- 現在遭遇している状況は、スケジューリング層が「同じワークフローの複数の定期トリガー」に対して制限/バグがあるか、または設定に時間競合、タイムゾーンなどの問題があり、結果として実行時に1つしかトリガーされない可能性が高いです。
- 公式が複数のスケジューラーの動作を明確にするまで、「2つのワークフローに分割する」または「1つの定期トリガー + 内部ルーティング」の方法で複数の計画タスクを実装することを優先的に推奨します。これは実際の運用においてより確実です。
もし可能であれば、まず「2つのワークフローに分割する」というソリューションを試して、両方が計画通りにトリガーされるか確認し、その結果を教えていただけると、公式にissueを提出する価値があるかどうかを検討できます。