So überprüfen Sie die Fehlerbehandlung, die Ihr Coding-Agent erstellt hat

Ihr Coding-Agent sagt, dass es Wiederholungsversuche und die Behandlung von Ratelimits hinzugefügt hat und seine Tests erfolgreich sind. Bevor Sie dem vertrauen, überprüfen Sie, wofür die Tests ausgeführt wurden.

In einem Test mit 3 Coding-Agents (210 Ausführungen) haben wir sie aufgefordert, Apps so zu gestalten, dass sie API-Fehler behandeln, und zu zeigen, dass es funktioniert. In 76% der 140-Ausführung, die nach Arbeitscode gefragt wurde, hat der Agent den Fehler von Hand mit Abruf-Stubs, httpx.MockTransportoder einem Throwaway-HTTP-Server erstellt. In den 75 Durchläufen, in denen die echte API verfügbar war und die Eingabeaufforderung sie nicht ausgeschlossen hat, testete 0 die App auf ihrer echten API-URL. Das Bestehen von Tests wie diesen beweist, dass der Code des Agents den Fehler behandelt, den der Agent angenommen hatte. Dies ist ein anderer Fehler als der fehler, den die API sendet.

Checklist

1. Fragen Sie, wogegen es getestet wurde. Fragen Sie den Agenten: "Welche URL hat die App während des Tests aufgerufen, und was hat den Fehler zurückgegeben?" Wenn es sich bei der Antwort um einen Stub oder einen lokalen Server handelt, den er geschrieben hat, behandeln Sie die Tests als Unit-Tests der hinzugefügten Codezweige.
2. Suchen Sie nach Schaltern, die für Tests hinzugefügt wurden. Durchsuchen Sie den Diff nach neuen Umgebungsvariablen, Basis-URL-Einstellungen oder Flags. In unserem Test fügten 61 der 105 Läufe von Apps, die GitHub, OpenAI oder eine Wetter-API aufrufen, einen hinzu. Entscheiden Sie, ob es in Produktion sein soll.
3. Überprüfen Sie den Code anhand des dokumentierten Verhaltens der API. Jede API schlägt auf eigene Weise fehl:
   • GitHub: Wenn Sie die primäre Ratenbegrenzung überschreiten, erhalten Sie 403 oder 429, wobei x-ratelimit-remaining auf 0 gesetzt ist, und warten Sie bis zu dem in x-ratelimit-reset angegebenen Zeitpunkt, in UTC-Epochensekunden. Warten Sie retry-after bei Sekundärratenlimits, bis sie vorhanden ist0, andernfalls bis x-ratelimit-reset zu x-ratelimit-remaining 1 Minute. Code, der nur 429 prüft, übersieht die 403er.
   • OpenAI: Einige 429s beziehen sich auf Abrechnungs- und Ausgabenlimits, wie credit_balance_exhausted z. B. . Es hilft nicht, sie erneut zu versuchen. Code, der es bei jedem 429-Fehler erneut versucht, verbirgt das Problem vor Ihnen.
   • Anthropic: Die spend cap 429 hat keine retry-after Kopfzeile, und Überlastungen geben 529 zurück, was Code, der nur Standardstatuscodes kennt, möglicherweise nicht erwartet.
4. Überprüfen Sie, wie es sich liest Retry-After. Der Header enthält entweder eine Anzahl von Sekunden oder ein HTTP-Datum (RFC 9110). Überprüfen Sie, ob der Code das von der API gesendete Format verarbeitet, die Anzahl der Versuche und die Gesamtwartedauer begrenzt und keine zusätzlichen Wiederholungsversuche über ein SDK ausführt, das bereits Wiederholungsversuche durchführt.
5. Überprüfen Sie, was der Benutzer sieht, wenn keine Wiederholungsversuche mehr übrig sind. Suchen Sie nach einer klaren Meldung anstelle eines Stacktrace oder eines endlosen Ladesymbols, und überprüfen Sie, ob der Benutzer seine Arbeit nicht verliert.
6. Führen Sie die App auf ihren echten URLs mit simulierten Fehlern aus. Dies ist der einzige Schritt, der zeigt, wie sich die ausgeführte App, ihr SDK und die Wiederholungsrichtlinie zusammen verhalten.

Überprüfen der vom Agenten verfassten Fehlerbehandlung

Probieren Sie es in Ihrer App aus

Dev Proxy fängt die Anfragen ab, die Ihre App an die echte API sendet, und liefert die von Ihnen ausgewählten Fehler zurück – ohne Änderungen am Code Ihrer App. Beginnen Sie bei häufig verwendeten APIs mit einem Preset. Um die GitHub-Rate-Limit-Behandlung zu überprüfen, hat Ihr Agent Folgendes geschrieben:

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

Führen Sie Ihre App aus, und beobachten Sie die Dev Proxy-Ausgabe. Die Voreinstellung gibt einen Wert von 429 mit GitHubs Rate-Limit-Headern zurück, sobald die App den Grenzwert überschreitet. Der RetryAfterPlugin in der Voreinstellung teilt Ihnen mit, ob ihre App die API erneut aufruft, bevor die Wartezeit abgelaufen ist. Die Voreinstellungen openai-throttling und anthropic-throttling bewirken dasselbe für anbieterseitige Rate-Limit-Fehler, und openai-throttling gibt auch einen credit_balance_exhausted-429 zurück, der nicht erneut versucht werden sollte.

Für andere APIs:

• Der GenericRandomErrorPlugin gibt Fehler zurück, die Sie definieren, und zwar mit einer von Ihnen gewählten Häufigkeit. Legen Sie den Satz mit --failure-rate fest. Siehe Meine App mit zufälligen Fehlern testen.
• Das LatencyPlugin verzögert Antworten, sodass Sie die Zeitüberschreitungen überprüfen können, die der Agent festgelegt hat. Siehe Simulation langsamer API-Antworten.

Sie können Ihren Codierungs-Agent auch bitten, die Dev Proxy-Konfiguration zu schreiben. Fügen Sie ihrem Agent den Dev Proxy MCP-Server hinzu, damit er die Dev Proxy-Dokumente und bewährte Methoden nachschlagen und überprüfen kann, welche Version Sie installiert haben. Überprüfen Sie diese Konfiguration wie jeden anderen Code, den der Agent schreibt.

Informationen zum Installieren von Dev Proxy finden Sie unter Einrichten von Dev Proxy.

Nächste Schritte

Siehe auch

• Mocks, Stubs, Fakes und Emulatoren: Testen von API-Aufrufen mit Coding-Agents
• 429 Zu viele Anfragen: Was dies bedeutet und wie sie behandelt werden
• Testen, wie Ihre App GitHub API-Ratenbeschränkungen behandelt
• Wiederholen nach Plugin
• Langsame API-Antworten simulieren