Cara memverifikasi penanganan kesalahan yang ditulis agen coding Anda

Agen coding Anda mengatakan ia menambahkan percobaan ulang dan penanganan rate limit, dan pengujiannya lulus. Sebelum Anda mempercayainya, periksa terhadap apa pengujian dijalankan.

Dalam pengujian, kami menjalankan dengan 3 agen pengkodian (210 eksekusi), kami meminta mereka untuk membuat aplikasi menangani kegagalan API dan menunjukkan bahwa aplikasi berfungsi. Dalam 76% dari 140 eksekusi yang meminta kode kerja, agen membuat ulang kegagalan secara manual dengan stub fetch, httpx.MockTransport, atau server HTTP throwaway. Dalam 75 kali percobaan di mana API nyata tersedia dan perintah tidak mengesampingkannya, 0 menguji aplikasi pada URL API aslinya. Lulus tes seperti ini membuktikan bahwa kode agen menangani kegagalan yang dibayangkan agen. Itu adalah kegagalan yang berbeda dari kegagalan yang dikirim oleh API.

Checklist

  1. Tanyakan terhadap apa pengujian dilakukan. Tanyakan kepada agen: "URL mana yang dipanggil aplikasi selama pengujian Anda, dan apa yang mengembalikan kesalahan?" Jika jawabannya adalah stub atau server lokal yang ditulisnya, perlakukan pengujian sebagai uji unit untuk cabang yang ditambahkannya.
  2. Cari sakelar yang ditambahkan untuk pengujian. Cari diff untuk variabel lingkungan baru, pengaturan URL dasar, atau flag. Dalam pengujian kami, 61 dari 105 eksekusi pada aplikasi yang memanggil GitHub, OpenAI, atau API cuaca menambahkan satu. Tentukan apakah Anda menginginkannya di production.
  3. Periksa kode terhadap perilaku API yang didokumenkan. Setiap API gagal dengan caranya sendiri:
    • GitHub: ketika Anda melebihi batas laju utama, Anda mendapatkan 403 atau 429 dengan x-ratelimit-remaining diatur ke 0, dan Anda menunggu hingga waktu dalam x-ratelimit-reset, dalam detik epoch UTC. Untuk batas laju sekunder, tunggu retry-after jika ada, jika tidak hingga x-ratelimit-reset jika x-ratelimit-remaining adalah 0, jika tidak, setidaknya 1 menit. Kode yang hanya memeriksa 429 melewatkan 403s.
    • OpenAI: beberapa error 429 adalah tentang batas penagihan dan pengeluaran, seperti credit_balance_exhausted. Mencoba kembali mereka tidak akan membantu. Kode yang mengulangi percobaan setiap menerima respons 429 menyembunyikan masalah dari Anda.
    • Anthropic: batas pengeluaran 429 tidak retry-after memiliki header, dan kelebihan beban mengembalikan 529, kode mana yang hanya mengetahui kode status standar yang mungkin tidak diharapkan.
  4. Periksa bagaimana bunyinya Retry-After. Header berisi salah satu dari sejumlah detik atau tanggal HTTP (RFC 9110). Periksa apakah kode menangani format yang dikirim API Anda, membatasi jumlah upaya dan total tunggu, dan tidak mencoba kembali di atas SDK yang sudah mencoba kembali.
  5. Periksa apa yang dilihat pengguna saat jatah percobaan ulang habis. Cari pesan yang jelas alih-alih stack trace atau spinner tanpa akhir, dan periksa apakah pengguna tidak kehilangan pekerjaan yang sedang mereka kerjakan.
  6. Jalankan aplikasi pada URL aslinya dengan kegagalan yang disimulasikan. Ini adalah satu-satunya langkah yang menunjukkan bagaimana aplikasi yang sedang berjalan, SDK-nya, dan kebijakan percobaan kembali bersifat bersama-sama.

Cara memverifikasi penanganan kesalahan yang ditulis agen

Approach Apa yang Anda temukan Yang Anda lewatkan
Baca diff Apakah kode terlihat benar Apakah itu berakibat tepat terhadap respons nyata API
Jalankan pengujian agen Bahwa cabang yang ditulisnya berjalan Semua yang tidak dimodelkan stub: kode status nyata, header, isi kesalahan, dan percobaan ulang SDK
Panggil API nyata sampai pemanggilan gagal Perilaku nyata Anda tidak dapat memicu kegagalan sesuai permintaan, dan Anda menghabiskan kuota nyata
Jalankan aplikasi pada URL nyata dengan kegagalan yang disimulasikan Bagaimana aplikasi yang sedang berjalan, SDK-nya, dan kebijakan percobaan kembali menangani kesalahan API sendiri Kode Anda dalam isolasi. Pertahankan pengujian unit agen untuk itu.

Coba di aplikasi Anda sendiri

Dev Proxy mencegat permintaan yang dikirim aplikasi Anda ke API nyata dan mengembalikan kesalahan yang Anda pilih, tanpa perubahan pada kode aplikasi Anda. Untuk API populer, mulailah dengan preset. Untuk memeriksa batas tarif GitHub penanganan agen Anda menulis:

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

Jalankan aplikasi Anda dan tonton output Dev Proxy. preset mengembalikan 429 dengan header rate limit GitHub setelah aplikasi Anda melampaui batas. RetryAfterPlugin dalam prasetel memberi tahu Anda jika aplikasi Anda memanggil API lagi sebelum waktu tunggu habis. Prasetelan openai-throttling dan anthropic-throttling melakukan hal yang sama untuk kesalahan batas laju milik penyedia sendiri, dan openai-throttling juga mengembalikan respons 429 credit_balance_exhausted yang tidak boleh dicoba lagi.

Untuk API lainnya:

Anda juga dapat meminta agen pengodian Anda untuk menulis konfigurasi Proksi Dev. Tambahkan server DEV Proxy MCP ke agen Anda sehingga dapat mencari dokumen Proksi Dev dan praktik terbaik dan memeriksa versi mana yang telah Anda instal. Tinjau konfigurasi tersebut seperti kode lain yang ditulis agen.

Untuk menginstal Dev Proxy, lihat Menyiapkan Dev Proxy.

Langkah berikutnya

Uji aplikasi saya dengan kesalahan acak

Baca juga

  • Terakhir diperbarui pada