LangChainコミュニティがリトライ条件の落とし穴を報告、単一の例外クラスで想定外のエラーが繰り返し実行される可能性

LangChainコミュニティは10月3日、エージェントのリトライ機構に関する問題を報告した。ModelRetryMiddleware または ToolRetryMiddleware で retry_on=TimeoutError と設定すると、タイムアウトだけをリトライするつもりでも、ほかの例外までリトライされる可能性があるという。報告者によると、LangChain 1.4.0のほか、開発ブランチでも再現した。確認時点でIssueは未解決のままで、関連する修正PRも記載されていない。コミュニティの報告

最小の再現ケースでは、ツールが常に KeyError を投げるようにし、リトライ回数を最大2回に設定している。報告された結果では、ツールは合計3回実行され、最初の失敗時に例外が送出されるのではなく、最終的にエラーメッセージが返された。報告者が共通の判定関数を調べたところ、コードはまず callable(retry_on) を確認していた。Pythonの例外クラスも呼び出し可能なため、判定関数として扱われてしまう。その結果、真と評価される例外オブジェクトが生成され、フィルタ条件が本来の意味を失っていた。再現コードと原因分析

ここには重要な前提がある。公式APIで retry_on に指定できると定義されているのは、「例外クラスのタプル」または「真偽値を返す関数」であり、単一のクラスはサポート対象として明記されていない。ドキュメントに従う場合は retry_on=(TimeoutError,) のように指定できる。要素が1つのタプルには末尾のカンマが必要だ。明示的な isinstance 判定関数を渡す方法もある。また、条件に一致しない例外はリトライ回数を使い切った後の処理に進まず、直ちに呼び出し元へ送出されるとドキュメントに記載されている。モデルリトライAPI

技術的な影響は、エージェントのフローが失敗をどう扱うかに及ぶ。ツール用ミドルウェアは、既定ではリトライを使い切ると ToolMessage を返し、モデルが処理を続けられるようにする。フィルタ設定が想定どおりに機能しない場合、本来なら処理を停止すべきプログラムエラーが、会話内のエラー結果として扱われる可能性がある。ツールリトライAPI 書き込みなどの副作用があるツールでは、繰り返し実行によって操作が重複するリスクも高まり得る。これはデプロイ上の推論であり、この報告で実際の事故が確認されたわけではない。

デプロイ担当者はリトライ引数を確認し、条件に一致しない例外が1回の実行で呼び出し元に返されることをテストするとよい。今後は、上流で入力検証が追加されるのか、単一の例外クラスが正式にサポートされるのかが注目点となる。現時点の根拠はコミュニティの再現例であり、正常な設定を含むすべての構成に影響すると結論づけることはできない。