Langflowコミュニティ、Phoenixのトレース分離の不具合を報告　並行ワークフローの記録が同一プロジェクトに送られる可能性

LangflowのGitHubコミュニティは10月5日、Phoenix連携における並行トレースの問題を報告した。同一プロセス内で2つのワークフローが交互に実行されると、異なるプロジェクト名を設定していても、LangChainのツールおよびチェーンの実行記録が最初のプロジェクトに送られる可能性がある。報告者は、改変していないLangflow 1.12.4パッケージを使い、逐次実行と並行実行の最小再現コードを提示した。現時点でイシューはオープンのままで、ページには修正ブランチやプルリクエストの記載がない。コミュニティの報告

報告では、原因としてArizePhoenixTracerのライフサイクルを挙げている。各ワークフローはプロセス全体に適用されるLangChainInstrumentor.instrument()を呼び出し、それぞれのトレースプロバイダーを渡した後、終了時にuninstrument()を呼び出す。事例の分析によると、2回目のインストゥルメンテーションでは独立したプロバイダーが作られず、2つのワークフローが最初のプロジェクトの送信先を共有する。そのため、一方のワークフローが終了した際、もう一方がまだ使用中のトレースフックまで解除される可能性もある。仕組みの分析

再現コードではメモリー内のspanエクスポーターを使い、2つのワークフローに異なるメタデータマーカーを付与している。逐次実行では、各プロジェクトにそれぞれTOOLとCHAINの記録が届く。並行実行では、両方のマーカーが最初のプロジェクトに現れ、2番目のプロジェクトには対応する記録がない。この結果はプロジェクトの割り当てが誤るという報告を裏付けるが、実際のリモートPhoenixコレクターを使ったテストではなく、モデルの出力やツールの結果への影響も示されていない。再現方法と制約

技術上のリスクは、オブザーバビリティーデータの信頼性にある。Phoenixの公式ドキュメントでは、記録の所属プロジェクトをproject_nameで指定する。Langflowのドキュメントによると、この連携はLangChainとコンポーネントのトレースを収集し、spanをデータセットに追加できる。そのため、プロジェクトの割り当てが混乱すると、エンジニアが遅延やエラーを生じさせたフローを誤認したり、その後の評価用データに別のフローのサンプルが混入したりする可能性がある。これはドキュメントに記載された用途から導かれる影響であり、テナントをまたぐデータ漏えいが確認されたわけではない。Phoenixの設定、Langflowの連携ドキュメント

この連携を利用するチームは、異なるプロジェクト名と実行マーカーを使って、ワークフローが交互に実行される際の記録の割り当てを確認できる。また、一方のフローが終了した後も、もう一方がspanを出力し続けるかをテストするとよい。今後は、上流でトレースフックのインストゥルメンテーションのライフサイクルを個々のワークフローから切り離す修正が行われるか、また回帰テストがプロジェクト分離と早期終了の両方を対象とするかが注目される。