コーディング エージェントが記述したエラー処理を確認する方法

コーディング エージェントは、再試行とレート制限の処理を追加し、テストは通っていると言います。 それを信頼する前に、テストが何を対象に実行されたか確認してください。

3 つのコーディング エージェント (210 回の実行) で実施したテストでは、アプリで API の障害を処理し、アプリが動作することを示すよう依頼しました。 作業コードを要求した 140 回の実行のうち 76% では、エージェントはフェッチ スタブ、httpx.MockTransport、または使い捨ての HTTP サーバーを使用して障害を手作業で再現しました。 実際の API が使用可能で、プロンプトで除外されなかった 75 の実行では、実際の API URL でアプリをテストした実行は 0 件でした。 このようなテストに合格すると、エージェントのコードがエージェントが想像した障害を処理することが証明されます。 これは、API が送信するエラーとは異なる失敗です。

Checklist

  1. 何を対象にテストしたのかを尋ねます。 エージェントに「テスト中にアプリが呼び出した URL と、何がエラーを返したか」を尋ねてください。回答がスタブまたは作成したローカル サーバーの場合は、追加したブランチの単体テストとしてテストを扱います。
  2. テスト用に追加されたスイッチを探します。 差分内で新しい環境変数、ベース URL 設定、またはフラグを検索します。 このテストでは、GitHub、OpenAI、または天気 API を呼び出すアプリでの 105 回の実行のうち 61 回で、1 つ追加しました。 本番環境にするかどうかを決定します。
  3. API の文書化された動作に照らしてコードを確認します。 各 API は、それぞれ独自の形で失敗します：
    • GitHub: プライマリ レート制限を超えると、x-ratelimit-remaining が返され、0 が に設定されます。その後、x-ratelimit-reset の時刻 (UTC エポック秒) まで待機します。 セカンダリ レート制限の場合は、retry-after が存在する場合は待機します。それ以外の場合は、0 が x-ratelimit-reset の場合は x-ratelimit-remaining まで、それ以外の場合は 1 分以上待ちます。 429 のみをチェックするコードでは、403 が見落とされます。
    • OpenAI: 一部の 429 は、credit_balance_exhaustedに関するものです。 それらを再試行しても役に立ちません。 429 エラーのたびに再試行するコードでは、問題が見えなくなります。
    • Anthropic: 支出上限 429 にはretry-afterヘッダーがなく、オーバーロードは 529 を返します。標準のステータスコードしか知らないコードでは、これを想定していない可能性があります。
  4. Retry-Afterがどう読めるか確認します。 ヘッダーは、秒数または HTTP 日付 (RFC 9110) を保持します。 コードが API が送信する形式を処理し、試行回数と合計待機時間を制限し、既に再試行されている SDK の上で再試行しないことを確認します。
  5. 再試行が実行されたときにユーザーに表示される内容を確認します。 スタック トレースや無限のスピナーではなく、明確なメッセージを探し、ユーザーが作業を失っていないことを確認します。
  6. シミュレートされた障害を伴う実際の URL でアプリを実行します。 これは、実行中のアプリ、SDK、および再試行ポリシーがどのように動作するかを示す唯一の手順です。

エージェントが記述したエラー処理を確認する方法

Approach 見つけたもの 見逃したもの
差分を読む コードが正しく見えるかどうか API の実際の応答に対して正しく動作するかどうか
エージェントのテストを実行する それが書き込んだブランチが実行されること スタブが再現しなかったもの (実際の状態コード、ヘッダー、エラー本文、SDK の再試行)
失敗するまで実際の API を呼び出す 実際の挙動 オンデマンドで障害をトリガーすることはできません。実際のクォータを使用します
障害をシミュレートして実際の URL でアプリを実行する 実行中のアプリ、SDK、および再試行ポリシーが API 独自のエラーを処理する方法 独立したコード。 そのために、エージェントの単体テストを保持します。

アプリで試す

Dev Proxy は、アプリが実際の API に送信する要求をインターセプトし、選択したエラーを返します。アプリのコードを変更せずに利用できます。 よく使われる API の場合は、プリセットから始めます。 エージェントが書き込んだGitHubレート制限の処理を確認するには:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

アプリを実行し、Dev Proxy の出力を確認します。 プリセットは、アプリが制限を超えると、GitHubのレート制限ヘッダーを含む 429 を返します。 プリセットの RetryAfterPlugin は、待機時間が終了する前にアプリが API を再度呼び出した場合に知らせます。 openai-throttlingプリセットとanthropic-throttlingプリセットは、プロバイダー独自のレート制限エラーに対して同じ処理を行い、openai-throttlingも再試行すべきではないcredit_balance_exhausted 429を返します。

その他の API の場合:

また、開発プロキシ構成を記述するようにコーディング エージェントに依頼することもできます。 Dev Proxy MCP サーバー をエージェントに追加して、Dev Proxy のドキュメントとベスト プラクティスを調べて、インストールしたバージョンを確認できるようにします。 エージェントが書く他のコードと同様に、その設定を確認します。

開発プロキシをインストールするには、「 開発プロキシの設定」を参照してください。

次のステップ

ランダム エラーでアプリをテストする

参照

  • Last updated on