Så här verifierar du felhanteringen som din kodagent skrev

Kodningsagenten säger att den lade till återförsök och hastighetsbegränsningshantering och att dess tester godkänns. Innan du litar på det kontrollerar du vad testerna kördes mot.

I ett test som vi körde med 3 kodningsagenter (210 körningar) bad vi dem att få appar att hantera API-fel och visa att det fungerar. I 76 % av de 140 körningar som efterfrågade fungerande kod återskapade agenten felet för hand med fetch stubs, httpx.MockTransport eller en throwaway HTTP-server. I de 75 körningar där det verkliga API:et var tillgängligt och uppmaningen inte uteslöt det, testade 0 körningar appen på dess verkliga API-URL. Att klara tester som dessa bevisar att agentens kod hanterar det fel som agenten föreställde sig. Det är ett annat fel än det som API:et skickar.

Checklista

  1. Fråga vad den testades mot. Fråga agenten: "Vilken URL anropade appen under testet och vad var det som returnerade felet?" Om svaret är en stub eller en lokal server som den skrev behandlar du testerna som enhetstester av de grenar som lagts till.
  2. Leta efter flaggor som har lagts till för tester. Sök i diffet efter nya miljövariabler, bas-URL-inställningar eller flaggor. I vårt test lade 61 av de 105 körningarna på appar som anropar GitHub, OpenAI eller ett väder-API till en. Bestäm om du vill ha det i produktion.
  3. Kontrollera koden mot API:ets dokumenterade beteende. Varje API misslyckas på sitt eget sätt:
    • GitHub: när du överskrider den primära hastighetsgränsen får du 403 eller 429 med x-ratelimit-remaining inställt på 0, och du väntar tills tiden i x-ratelimit-reset, i UTC-epoksekunder. För sekundära hastighetsbegränsningar, vänta på retry-after om det finns där, annars tills x-ratelimit-reset om x-ratelimit-remaining är 0, annars minst 1 minut. Kod som bara kontrollerar 429 missar 403s.
    • OpenAI: vissa 429:er handlar om fakturerings- och utgiftsgränser, till exempel credit_balance_exhausted. Det hjälper inte att försöka igen. Kod som försöker igen vid varje 429-svar döljer problemet för dig.
    • Anthropic: utgiftsgränsen 429 har ingen retry-after header, och överbelastningar returnerar 529, något som kod som bara känner till standardstatuskoder kanske inte förväntar sig.
  4. Kontrollera hur det låter Retry-After. Huvudet innehåller antingen ett antal sekunder eller ett HTTP-datum (RFC 9110). Kontrollera att koden hanterar det format som api:et skickar, begränsar antalet försök och den totala väntetiden och försöker inte igen ovanpå ett SDK som redan försöker igen.
  5. Kontrollera vad användaren ser när återförsöken tar slut. Leta efter ett tydligt meddelande i stället för en stackspårning eller en oändlig spinnare och kontrollera att användaren inte förlorar sitt arbete.
  6. Kör appen på sina faktiska URL:er med simulerade fel. Det här är det enda steget som visar hur den app som körs, dess SDK och dess återförsöksprincip fungerar tillsammans.

Så här verifierar du felhantering som skrivits av agenten

Approach Det här hittar du Vad du saknar
Läs diffen Om koden ser rätt ut Om det beter sig rätt mot API:ets verkliga svar
Kör agentens tester Att de grenar som den skrev körs Allt som stuben inte modellerade: verkliga statuskoder, headers, felkroppar och SDK-återförsök
Anropa det verkliga API:et tills anropet misslyckas Faktiskt beteende Du kan inte utlösa fel på begäran och du förbrukar faktisk kvot
Kör appen på verkliga URL:er med simulerade fel Hur appen som körs, dess SDK och dess återförsöksprincip hanterar API:ets egna fel Din kod i isolering. Behåll agentens enhetstester för det.

Prova det i din app

Dev Proxy fångar upp begäranden som din app skickar till det verkliga API:et och returnerar de fel du väljer, utan ändringar i appens kod. För populära API:er börjar du med en förinställning. För att kontrollera GitHubs hantering av hastighetsbegränsningar skrev din agent:

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

Kör din app och titta på Dev Proxy-utdata. Förinställningen returnerar en 429 med GitHub hastighetsgränsrubriker när appen överskrider gränsen. RetryAfterPlugin i förinställningen talar om för dig om din app anropar API:et igen innan väntetiden är slut. Förinställningarna openai-throttling och anthropic-throttling gör samma sak för providerns egna hastighetsbegränsningsfel, och openai-throttling returnerar också en credit_balance_exhausted 429 som inte bör försökas igen.

För andra API:er:

Du kan också be kodningsagenten att skriva dev proxy-konfigurationen. Lägg till DEV Proxy MCP-servern till din agent så att den kan leta upp Dev Proxy-dokumenten och bästa praxis och kontrollera vilken version du har installerat. Granska den konfigurationen som all annan kod agenten skriver.

Information om hur du installerar Dev Proxy finns i Installera Dev Proxy.

Nästa steg

Testa min app med slumpmässiga fel

Se även

  • Uppdaterades senast