Difyコミュニティ、Agentのファイルをアップロード後に取得できない問題に対するスケジュール実行時のID修正を提案

Difyコミュニティは10月26日、新しいAgentノードを含むワークフローについて、Studioから手動実行するとファイルを正常に生成できる一方、スケジュール実行では ToolFile not found が発生すると報告した。報告者はセルフホストのKubernetes環境を使用しており、ファイルのアップロードは成功するものの、その直後にダウンロード要求が失敗することを確認した。Agentノードは成功と表示されるが、files 変数がないため後続処理が中断するという。問題の報告

この種の障害は、自動レポートの配信に直接影響する。Difyの公式ドキュメントでは、Schedule Triggerはワークフローを定期実行するための入口とされており、ビジュアルインターフェースまたはcronで周期を設定し、日次レポートや通知などに利用できる。この用途を踏まえると、エディター内の手動テストに成功しただけでは、バックグラウンドのスケジュール実行でファイルを配信できることの確認にはならない。公式スケジュール実行ドキュメント

修正候補によると、問題は呼び出し元とユーザーIDの判定方法に一貫性がないことにある。スケジュール実行は SERVICE_API を呼び出し元として実行されるが、実際の起動元はワークスペースの Account である。ところが実行エンジンは呼び出し元に基づき、そのアカウントを end-user として扱っていた。アップロード時にはファイルがマッピング後のエンドユーザーに紐づけられる一方、ダウンロード時には元のアカウントIDで検索するため、両者が同じレコードを参照できない。PR #44799は、実際のユーザーオブジェクトをまだ参照できる入口でロールを記録し、実行エンジンがそのロールを優先して引き継ぐことを提案している。ID引き継ぎの修正

もう一つのPR #44796は、一時停止時のスナップショットと実行再開にも対応し、ロールが記録されていない旧形式のスナップショットとの互換性も考慮している。作者によると、ファイルの作成とダウンロード時の再構築、他のユーザーやテナントによるアクセスの拒否を含む関連テスト103件に合格した。ただし、外部Agentサービスやデプロイ済みのスケジュールワークフローはローカルテストでは検証していない。確認時点で2件の提案はいずれもオープンであり、正式リリースで修正済みとは言えない。エンジニアリングチームは今後、マージとリリースの状況を確認し、実際のスケジュール実行で初回実行、一時停止後の再開、ファイル権限の整合性を検証する必要がある。修正案と検証範囲