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. Bei 76 % der 140 Ausführungen, die nach Arbeitscode gebeten haben, hat der Agent den Fehler mit Stubs abrufen, httpx.MockTransportoder einem Wegwerf-HTTP-Server manuell erstellt. In den 75 Ausführungen, in denen die tatsächliche API verfügbar war und der Prompt sie nicht ausgeschlossen hat, testeten keine davon die App auf ihrer tatsächlichen API-URL. Das Bestehen solcher Tests 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 Einheitstests der hinzugefügten Codeverzweigungen.
  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 Ausführungen 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-Fehler, wobei x-ratelimit-remaining auf 0 festgelegt ist. Warten Sie bis zu dem in x-ratelimit-reset angegebenen Zeitpunkt, in UTC-Epochensekunden. Warten Sie bei Sekundärratenbegrenzungen auf retry-after, wenn es vorhanden ist. Andernfalls warten Sie bis x-ratelimit-reset, wenn x-ratelimit-remaining0 ist, sonst mindestens 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. . Erneutes Versuchen hilft nicht. Code, der es bei jedem 429-Fehler erneut versucht, verbirgt das Problem vor Ihnen.
    • Anthropic: Die Ausgabenobergrenze 429 hat keinen retry-after Header, und Überladungen geben 529 zurück, was von Code, der nur Standardstatuscodes kennt, möglicherweise nicht erwartet wird.
  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

Approach Was Sie finden Was Sie verpassen
Diff lesen Ob der Code richtig aussieht Ob es sich gegenüber den echten Antworten der API korrekt verhält
Tests des Agent ausführen Dass die von ihm geschriebenen Verzweigungen ausgeführt werden Alles, was der Stub nicht modelliert hat: echte Statuscodes, Header, Fehlertexte und SDK-Wiederholungen
Rufen Sie die echte API auf, bis ein Fehler auftritt Tatsächliches Verhalten Es können bei Bedarf keine Fehler ausgelöst werden und es wird tatsächliches Kontingent verbraucht
Die App auf tatsächlichen URLs mit simulierten Fehlern ausführen So verarbeiten die ausgeführte App, ihr SDK und ihre Wiederholungsstrategie die Fehler der API selbst Ihr isolierter Code. Behalten Sie dafür die Einheitstests des Agents.

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 die Rate mit --failure-rate fest. Informationen finden Sie unter 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. Informationen finden Sie unter Langsamer API-Antworten simulieren.

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

Testen meiner App mit zufälligen Fehlern

Siehe auch

  • Zuletzt aktualisiert um