Come verificare la gestione degli errori scritta dal tuo agente di coding

L'agente di codifica indica che sono stati aggiunti nuovi tentativi e la gestione dei limiti di frequenza e i test risultano superati. Prima di considerare attendibile questo aspetto, controlla su cosa sono stati eseguiti i test.

In un test che abbiamo eseguito con 3 agenti di codifica (210 esecuzioni), è stato chiesto loro di gestire gli errori dell'API e di mostrare che funzionano. Nel 76% delle 140 esecuzioni che hanno richiesto codice funzionante, l'agente ha ricreato manualmente il problema con stub di fetch, httpx.MockTransport, o un server HTTP usa e getta. Nelle 75 esecuzioni in cui era disponibile l'API reale e il prompt non lo escludeva, in 0 casi è stata testata l'app sull'URL dell'API reale. Il superamento di test come questi dimostra che il codice dell'agente gestisce l'errore immaginato dall'agente. Si tratta di un errore diverso da quello inviato dall'API.

Checklist

1. Chiedi rispetto a cosa è stato testato. Chiedi all'agente: "Quale URL ha chiamato l'app durante il test e quale chiamata ha restituito l'errore?" Se la risposta è uno stub o un server locale scritto dall'agente, considerare i test come unit test dei rami aggiunti.
2. Cercare gli interruttori aggiunti per i test. Cercare nel diff le nuove variabili di ambiente, le impostazioni dell'URL di base o i flag. Nel nostro test, 61 delle 105 esecuzioni nelle app che chiamano GitHub, OpenAI o un'API meteo hanno aggiunto una chiamata. Decidi se lo desideri nell'ambiente di produzione.
3. Controllare il codice in base al comportamento documentato dell'API. Ogni API fallisce a modo suo:
   • GitHub: quando si supera il limite di frequenza primaria, si ottiene 403 o 429 con x-ratelimit-remaining impostato su 0 e si attende fino all'ora in x-ratelimit-reset, in secondi epoch UTC. Per i limiti di frequenza secondaria, attendere retry-after se è presente, altrimenti fino a x-ratelimit-reset se x-ratelimit-remaining è 0, altrimenti almeno 1 minuto. Il codice che verifica solo la presenza di 429 ignora i 403.
   • OpenAI: alcuni errori 429 sono relativi alla fatturazione e ai limiti di spesa, ad esempio credit_balance_exhausted. Riprovarci non aiuterà. Il codice che ritenta ogni 429 nasconde il problema a te.
   • Anthropic: il limite di spesa 429 non ha header retry-after e gli overload restituiscono 529, che il codice che conosce solo i codici di stato standard potrebbe non aspettarsi.
4. Controllare come si legge Retry-After. L'intestazione contiene un numero di secondi o una data HTTP (RFC 9110). Verificare che il codice gestisca il formato inviato dall'API, limiti il numero di tentativi e l'attesa totale e non riprovi in aggiunta ai retry di un SDK che ritenta già.
5. Controllare cosa vede l'utente quando i tentativi si esauriscono. Cercare un messaggio chiaro anziché un'analisi dello stack o uno spinner infinito e verificare che l'utente non perda il proprio lavoro.
6. Eseguire l'app negli URL reali con guasti simulati. Questo è l'unico passaggio che mostra come si comportano insieme l'app in esecuzione, il relativo SDK e i relativi criteri di ripetizione.

Come verificare la gestione degli errori scritta dall'agente

Provalo nella tua app

Dev Proxy intercetta le richieste inviate dall'app all'API reale e restituisce gli errori scelti, senza modifiche al codice dell'app. Per le API più diffuse, parti da un preset. Per controllare la gestione del limite di richieste GitHub l'agente ha scritto:

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

Eseguire l'app e osservare l'output di Dev Proxy. Il set di impostazioni restituisce un valore 429 con gli header di rate limit di GitHub quando l'app supera il limite. Il set di impostazioni RetryAfterPlugin indica se l'app chiama nuovamente l'API prima che il tempo di attesa scada. openai-throttling e anthropic-throttling fanno lo stesso per gli errori di limite di velocità del provider e openai-throttling restituisce anche un credit_balance_exhausted 429 che non deve essere riprovato.

Per altre API:

• GenericRandomErrorPlugin restituisce gli errori che definisci alla frequenza che scegli. Impostare il tasso con --failure-rate. Vedi Vedi l'app con errori casuali.
• LatencyPlugin ritarda le risposte in modo da poter controllare i timeout impostati dall'agente. Vedi Simulare risposte API lente.

È anche possibile chiedere al coding agent di scrivere la configurazione di Dev Proxy. Aggiungere il server MCP Dev Proxy all'agente in modo che possa cercare la documentazione di Dev Proxy e le procedure consigliate e controllare la versione installata. Esaminare questa configurazione come qualsiasi altro codice che l'agente scrive.

Per installare Dev Proxy, vedere Configurare Dev Proxy.

Passaggi successivi

Vedere anche

• Mock, stub, fake ed emulatori: test delle chiamate API con agenti di codifica
• 429 Troppe richieste: cosa significa e come gestirlo
• Testare il modo in cui l'app gestisce i limiti di frequenza dell'API di GitHub
• RetryAfterPlugin
• Simulare risposte API lente