Hoe controleert u de foutafhandeling die uw codeeragent heeft geschreven?

Uw codeeragent zegt dat er nieuwe pogingen en rate-limitafhandeling zijn toegevoegd en dat de tests zijn geslaagd. Voordat u dat vertrouwt, controleert u waartegen de tests zijn uitgevoerd.

In een test die we hebben uitgevoerd met 3 codingagents (210 uitvoeringen), hebben we hen gevraagd apps API-fouten te laten verwerken en te laten zien dat dit werkt. In 76% van de 140 uitvoeringen waarin om werkende code werd gevraagd, heeft de agent de fout handmatig gebouwd met fetch-stubs, httpx.MockTransport, of een wegwerp-HTTP-server. In de 75 uitvoeringen waar de echte API beschikbaar was en de prompt deze niet heeft uitgesloten, heeft 0 de app getest op de echte API-URL. Het slagen voor tests als deze bewijst dat de code van de agent de fout afhandelt die de agent zich heeft voorgesteld. Dat is een andere fout dan de fout die de API verzendt.

Controlelijst

  1. Vraag waartegen het is getest. Vraag de agent: 'Welke URL heeft de app aangeroepen tijdens de test en wat de fout heeft geretourneerd?' Als het antwoord een stub of een lokale server is die de app zelf heeft opgezet, behandelt u de tests als eenheidstests van de toegevoegde vertakkingen.
  2. Zoek naar switches die zijn toegevoegd voor tests. Zoek in de diff naar nieuwe omgevingsvariabelen, basis-URL-instellingen of vlaggen. In onze test voegden 61 van de 105 runs op apps die GitHub, OpenAI of een weer-API aanroepen er een toe. Bepaal of u het in productie wilt.
  3. Controleer de code op basis van het gedocumenteerde gedrag van de API. Elke API mislukt op zijn eigen manier:
    • GitHub: wanneer u de primaire frequentielimiet overschrijdt, krijgt u 403 of 429 met x-ratelimit-remaining ingesteld op 0, en wacht u tot de tijd in x-ratelimit-reset, in UTC epoch seconden. Wacht voor secundaire frequentielimieten op retry-after als deze er is, anders tot x-ratelimit-remaining als x-ratelimit-reset0 is, anders ten minste 1 minuut. Code die alleen op 429 controleert, mist de 403's.
    • OpenAI: sommige 429's gaan over facturerings- en uitgavenlimieten, zoals credit_balance_exhausted. Ze opnieuw proberen helpt niet. Code die na elke 429 opnieuw probeert, verbergt het probleem voor u.
    • Anthropic: de uitgavenlimiet 429 heeft geen retry-after header en overbelastingen retourneren 529, wat code die alleen standaardstatuscodes kent mogelijk niet verwacht.
  4. Controleer hoe het leest Retry-After. De header bevat een aantal seconden of een HTTP-datum (RFC 9110). Controleer of de code de indeling afhandelt die uw API verzendt, het aantal pogingen en de totale wachttijd beperkt en geen retries uitvoert boven op een SDK die zelf al retries doet.
  5. Controleer wat de gebruiker ziet wanneer de pogingen op zijn. Zoek naar een duidelijk bericht in plaats van een stack-trace of een eindeloze spinner en controleer of de gebruiker zijn werk niet kwijtraakt.
  6. Voer de app uit op de echte URL's met gesimuleerde fouten. Dit is de enige stap die laat zien hoe de actieve app, de SDK en het beleid voor opnieuw proberen zich samen gedragen.

Door agents geschreven foutafhandeling controleren

Approach Wat u vindt Wat u mist
Lees de diff Of de code er goed uitziet Of het zich goed gedraagt met de echte responses van de API
De tests van de agent uitvoeren Dat de branches die het heeft aangemaakt worden uitgevoerd Alles wat de stub niet modelde: echte statuscodes, headers, foutteksten en nieuwe pogingen van de SDK
De echte API aanroepen totdat deze mislukt Feitelijk gedrag U kunt geen mislukkingen op aanvraag activeren en u besteedt echt quotum
De app uitvoeren op echte URL's met gesimuleerde fouten Hoe de draaiende app, de SDK en het beleid voor opnieuw proberen de eigen fouten van de API verwerken Uw code afzonderlijk. Houd hiervoor de unittests van de agent.

Probeer het in uw app

Dev Proxy onderschept de aanvragen die uw app verzendt naar de echte API en retourneert de fouten die u kiest, zonder wijzigingen in de code van uw app. Voor populaire API's begint u met een preset. Om de afhandeling van de GitHub-frequentielimiet te controleren, schreef uw agent:

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

Voer uw app uit en bekijk de uitvoer van de Dev Proxy. De voorinstelling retourneert een 429 met de snelheidslimietheaders van GitHub zodra uw app de limiet overschrijdt. De RetryAfterPlugin in de voorinstelling geeft aan of uw app de API opnieuw aanroept voordat de wachttijd op is. De openai-throttling en anthropic-throttling voorinstellingen doen hetzelfde voor de eigen frequentielimietfouten van de provider en openai-throttling retourneert ook een credit_balance_exhausted 429 die niet opnieuw moet worden geprobeerd.

Voor andere API's:

U kunt uw coderingsagent ook vragen om de Dev Proxy-configuratie te schrijven. Voeg de Dev Proxy MCP server toe aan uw agent, zodat deze de Dev Proxy-documentatie en best practices kan opzoeken en kan controleren welke versie u hebt geïnstalleerd. Controleer die configuratie net als alle andere code die de agent schrijft.

Om Dev Proxy te installeren, raadpleegt u Dev Proxy instellen.

Volgende stappen 

Mijn app testen met willekeurige fouten

Zie ook

  • Laatst bijgewerkt om