同じワークフロー内の2つのタイマートリガー、片方が起動しない

ワークフローが1つあり、2つのタイマートリガーがあります。そのうちの1つは毎日設定された時間にトリガーされますが、もう1つはトリガーされません。手動テストでは問題ありません。ログでも、毎日1つのトリガーのみがトリガーされていることが確認できます。
現在、Difyは同じワークフローで「複数のトリガーの並行実行」をサポートしていますか?
ありがとうございます。

@Dify_Forum_Helper ヘルプ

現在、Difyのワークフローにおける「定期トリガー」は、設計上、1つのワークフローに複数のトリガーを配置することをサポートしていますが、いくつかの落とし穴があり、ご説明の現象(1つは時間通りにトリガーされるが、もう1つは手動テストでは成功するものの、計画通りには実行されない)を引き起こす可能性があります。

まず結論から申し上げます。

  • 概念的には「1つのワークフローで複数のトリガーが並行して実行される」ことをサポートしています。
  • しかし、現在のバージョンでは、定期トリガーに関して、いくつかの制限/バグ、または設定の詳細に問題がある可能性があり、実際の効果は「1つしか実行されない」ことが多いです。以下に、いくつかのトラブルシューティングの方向性と、確実な推奨ソリューションを提示します。

一、まず確認すべきいくつかの重要な点

以下の項目を一つずつ確認してください。

  1. 2つの定期トリガーの有効化状態

    • 両方とも「無効」になっていませんか?インターフェースには通常、enable/disableまたはスイッチがあります。
    • ノードをコピーした後、新しい定期トリガーがデフォルトでオフまたは未保存になっている場合があります。
  2. 時間設定が競合/重複していないか

    • 例えば:
      • 一方が「毎日10:00」、もう一方も「毎日10:00」または非常に近い時間である場合。
      • スケジューリングの実装によっては、同じワークフローの同じ時刻における複数の計画を「マージ」したり、「1つだけ保持」したりするものがあります。
    • まずテストとして、2つ目のトリガーを完全に異なる時間(例:1つは10:00、もう1つは10:05)に変更し、2つ目が正常に実行されるか確認することをお勧めします。
  3. タイムゾーンの問題

    • Difyの定期タスクはどのタイムゾーンで実行されますか?
    • サーバー/Difyの設定がAsia/Shanghaiではなく、インターフェースで現地時間として理解している場合、実際にはすでにトリガーされているのに、時間を見間違えている可能性があります。
    • 比較してください:
      • 定期トリガーの設定時間
      • ログに記録されたトリガー時間
        8時間/数時間のずれがないか確認してください。
  4. トリガーログで2つのトリガーを区別できるか

    • 通常、各トリガーノードには独自のID/名前があります。ログで「毎日1つだけトリガーされている」と表示される場合:
      • 実際に1つのノードの記録しか見えないのか、それとも2つのノードが実行されたが、その後のプロセスがマージされたのか?
    • もし区別できるのであれば、これら2つの定期トリガーに明確に異なる名前を付けて、ログで検索しやすくしてください。
  5. 同じ「入口」下流ノードを使用しているか

    • 例えば、2つの定期トリガーが同じ下流ノードに接続されており、このノードまたは後続のノードに何らかの「排他」ロジック(例:シングルタスク、ロック、レート制限)がある場合、1つだけが実行されているように見えることがあります。

二、現在存在する可能性のある設計上の制限/実装の詳細

一部のバージョン/実装では、スケジューラーが「同じワークフローの複数のスケジュール」に対して、以下のいずれかの状況になる可能性があります。

  • 同じアプリ/ワークフローに「単一のスケジュールをバインド」し、最初の設定のみが有効になる。
  • または、スケジューラーサービスにバグがあり、複数のcronのうち1つしか有効にならない。
  • あるいは、最大同時実行タスク数再入防止の制限がある:
    • 例えば、ある時点でワークフローがすでに実行中の場合、スケジューラーは新しいトリガーをスキップし、同じワークフローの再入を防ぎます。
    • 最初のトリガーの実行時間が長い場合、同じ時間枠でトリガーされた2番目のトリガーはスキップされます。

現在、バージョンに対応するソースコードやissueリストを直接確認できないため、一般的なワークフロースケジューリングの実装に基づいて推測するしかありません。
確実を期すため、現時点では次のように理解してください:設計目標は複数の定期トリガーをサポートすることですが、特定のバージョン/シナリオでは動作が完全に安定しない、または1つしか有効にならない場合があります


三、推奨される安定したソリューション

これらの実装の詳細に悩まされないために、実践的により確実な2つのソリューションを提案します。

ソリューションA:2つのワークフローに分割し、それぞれに1つの定期トリガーを設定する

  1. 現在のワークフローロジックを次のように分割します。
    • ワークフローA:「定期トリガーA + 対応する分岐ロジック」のみを保持します。
    • ワークフローB:「定期トリガーB + 対応する分岐ロジック」のみを保持します。
  2. それぞれ個別に定期タスクを設定します。
  3. これにより、スケジューリング上は完全に独立した2つの計画タスクとなり、互いに影響しません。

利点:

  • 最も直感的で、落とし穴が少ないです。
  • ログと問題のトラブルシューティングが非常に明確です。どれが実行されなかったか一目でわかります。
  • 「同じワークフローの複数のスケジューラー」の現在のバージョン固有の実装に依存しません。

ソリューションB:1つの定期トリガーを保持し、「ルーティング/条件ノード」で内部的に区別する

  1. ワークフローの入口に1つの「定期トリガー」のみを保持します。
  2. 定期トリガーの後、「条件判断/Routerノード」を接続します。
    • ここで「現在の時間/日付/カスタム変数」に基づいて、どちらのパスに進むかを判断します。
      • 例えば:
        • 毎日10:00に1回トリガー
        • ワークフロー内で判断:今日が平日であれば → パス1に進む。そうでなければ → パス2に進む。
        • または、日付を2で割った余り、7で割った余り、曜日などの条件で分岐します。
  3. 毎日固定の2つの異なる時間帯に2つのロジックを実行したい場合は、次のようにできます。
    • 1つの定期トリガーの頻度を少し高く設定します(例えば30分ごとに実行しますが、内部条件で10:00±数分のウィンドウを満たす場合のみ「ロジックA」を実行し、15:00±数分のウィンドウを満たす場合のみ「ロジックB」を実行し、それ以外の時間分岐は直接終了します)。

利点:

  • 「複数の定期トリガー」自体のスケジューリング互換性の問題を完全に回避します。
  • すべてのロジックが1つのワークフローに集中しているため、メンテナンスと全体の状態の確認が容易です。

四、確認/補足していただきたい情報

もし引き続きトラブルシューティングにご協力いただけるのであれば、以下の情報をご提供いただけると、より具体的に原因を推測できます。

  1. Difyのバージョン番号(設定ページまたはdocker-composeでイメージタグを確認できます)。
  2. 2つの定期トリガーの具体的な設定方法(例:
    • トリガー1:毎日10:00
    • トリガー2:毎日18:00
      タイムゾーンの設定はどうなっていますか?
  3. ログに2番目のトリガーノードの実行記録が何か見られますか(ノード名/IDのスクリーンショットまたはテキスト説明で構いません)。
  4. 2つのトリガーの下流は一部のノードを共有していますか、それとも完全に独立した2つの経路ですか?

まとめ

  • 理論上:Difyは「同じワークフローに複数のトリガーが存在する」ことをサポートしています。
  • 現在遭遇している状況は、スケジューリング層が「同じワークフローの複数の定期トリガー」に対して制限/バグがあるか、または設定に時間競合、タイムゾーンなどの問題があり、結果として実行時に1つしかトリガーされない可能性が高いです。
  • 公式が複数のスケジューラーの動作を明確にするまで、「2つのワークフローに分割する」または「1つの定期トリガー + 内部ルーティング」の方法で複数の計画タスクを実装することを優先的に推奨します。これは実際の運用においてより確実です。

もし可能であれば、まず「2つのワークフローに分割する」というソリューションを試して、両方が計画通りにトリガーされるか確認し、その結果を教えていただけると、公式にissueを提出する価値があるかどうかを検討できます。