Dify 1.19.0、ネストしたワークフローのトレースに対応　ローリングアップグレードでは新旧キューの振り分けが必要

Difyは11月4日に1.19.0をリリースし、ネストしたワークフローの内部ステップを外部トレースの対象に加えた。メインフローがWorkflow Toolを呼び出すと、ツール内で永続化された子ステップが、そのツール呼び出しのspan配下に記録される。これにより、繰り返しの呼び出し、失敗、さらに深い階層の呼び出しの関係を保ったまま、整形済みのプロンプト、応答、token使用量を確認できる。公式リリースノート

この変更により、再利用可能なフローのデバッグがしやすくなる。たとえば、同じツールを複数回呼び出したうち一度だけ失敗した場合、エンジニアは実行ツリーをたどって該当の呼び出しを特定し、モデルが受け取ったコンテキストを調べられる。これは追加されたトレース構造から導ける用途であり、公式はデバッグ時間の短縮を測定したデータを公表していない。Langfuseとの既存の連携は、引き続きDifyのMonitoring設定から有効にできる。プロジェクトの認証情報を作成すると、アプリのインターフェースまたはAPI呼び出しによってトレースデータが生成される。Langfuse連携ドキュメント

基盤部分も大きく再構成された。関連する変更では、重複していたトレース経路を共通パイプラインに統合し、ベンダーが一貫したインターフェースを通じて中立的なspanツリーを受け取るようにした。識別子は決定論的に生成され、再送時には同じレコードが更新される。送信失敗は、再試行可能、拒否、不明な結果に分類され、再試行の判断基準が明確になった。トレース再構成の提案

デプロイ時には、新しいタスクの送信先がデフォルトでops_trace_v2になる点に注意が必要だ。API、worker、Beatの設定を一致させ、カスタムのキュー購読にもこのキューを追加する必要がある。ローリングアップグレード中は、旧workerでops_traceの処理を続ける。旧プロデューサーを停止し、キュー内のタスクと遅延再試行中のタスクがなくなったことを確認してから旧workerを停止し、新旧の負荷が混在しないようにする。アップグレードとキュー引き継ぎの説明

より完全な階層構造が適用されるのは新しい実行のみで、過去のトレースは遡って更新されない。独立したネスト型フローは、引き続き親IDを使って別々のtraceを関連付ける。エンジニアリングチームはアップグレード後、繰り返し呼び出し、失敗、再試行のケースで実際のエクスポート結果を確認し、既存のダッシュボードが新しいspan構造を扱えることも確かめる必要がある。バージョンの制限事項