Como verificar o tratamento de erros escrito pelo seu agente de codificação

O teu agente de codificação diz que adicionou retentativas e gestão de limites de taxa, e os testes passam. Antes de confiares nisso, verifica contra o que os testes foram executados.

Num teste que fizemos com 3 agentes de programação (210 execuções), pedimos-lhes que fizessem as aplicações tratar falhas da API e mostrar que funcionava. Em 76% das 140 execuções que pediam código funcional, o agente construiu a falha manualmente com fetch stubs, ou httpx.MockTransport, ou um servidor HTTP descartável. Nas 75 execuções em que a API real estava disponível e o prompt não a descartou, 0 testaram a aplicação no URL real da API. Passar em testes como estes prova que o código do agente lida com a falha que o agente imaginou. Essa é uma falha diferente da que a API envia.

Lista de Verificação

  1. Pergunte contra o que foi testado. Pergunte ao agente: "Que URL é que a aplicação chamou durante o seu teste e qual devolveu o erro?" Se a resposta for um stub ou um servidor local que escreveu, trate os testes como testes unitários das branches que adicionou.
  2. Procure switches adicionados para testes. Procura no diff novas variáveis de ambiente, definições de URL base ou flags. No nosso teste, 61 das 105 execuções em aplicações que chamam o GitHub, a OpenAI ou uma API de meteorologia adicionaram uma chamada adicional. Decida se quer que esteja em produção.
  3. Verifique o código em relação ao comportamento documentado da API. Cada API falha à sua maneira:
    • GitHub: quando ultrapassa o limite principal de pedidos, obtém 403 ou 429 com x-ratelimit-remaining definido para 0, e espera até ao instante indicado em x-ratelimit-reset, em segundos da época UTC. Para limites de taxa secundários, aguarde retry-after se estiver disponível, caso contrário, aguarde até x-ratelimit-reset se x-ratelimit-remaining estiver 0, caso contrário pelo menos 1 minuto. Código que só verifica o 429 não deteta os 403.
    • OpenAI: alguns 429 são sobre faturação e limites de despesa, como credit_balance_exhausted. Tentar novamente essas ações não vai ajudar. O código que tenta novamente sempre que ocorre um 429 esconde-te o problema.
    • Anthropic: o código 429 de limite de gastos não tem cabeçalho retry-after, e as sobrecargas devolvem 529, algo que o código que só conhece códigos de estado padrão pode não esperar.
  4. Veja como soa Retry-After. O cabeçalho contém ou um número de segundos ou uma data HTTP (RFC 9110). Verifica se o código gere o formato que a tua API envia, limita o número de tentativas e o tempo total de espera, e não faz novas tentativas sobre um SDK que já faz novas tentativas.
  5. Verifique o que o utilizador vê quando as tentativas acabam. Procure uma mensagem clara em vez de um rastreio de pilha ou um spinner infinito, e verifique se o utilizador não perde o seu trabalho.
  6. Executa a aplicação nos seus URLs reais com falhas simuladas. Este é o único passo que mostra como a aplicação em execução, o seu SDK e a sua política de retentativas se comportam em conjunto.

Como verificar o tratamento de erros escrito pelo agente

Approach O que encontra Do que sente falta
Leia o diff Se o código parece correto Se se comporta corretamente face às respostas reais da API
Faz os testes do agente Que as ramificações que escreveu são executadas Tudo o que o stub não modelou: códigos de estado reais, cabeçalhos, corpos de erro e novas tentativas do SDK
Chame a API real até falhar Comportamento real Não podes desencadear falhas a pedido, e gastas uma quota real
Execute a aplicação em URLs reais com falhas simuladas Como a aplicação em execução, o seu SDK e a sua política de retentativas lidam com os próprios erros da API O teu código isoladamente. Mantenha os testes unitários do agente para isso.

Experimente na sua app

O Dev Proxy interceta os pedidos que a sua aplicação envia para a API real e devolve os erros que escolher, sem alterações ao código da sua aplicação. Para APIs populares, comece com um preset. Para verificar como o seu agente tratou o limite de taxa do GitHub:

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

Executa a tua aplicação e vê a saída do Dev Proxy. O preset devolve um 429 com os cabeçalhos do limite de taxa do GitHub assim que a tua aplicação ultrapassa esse limite. O RetryAfterPlugin na predefinição indica-te se a tua aplicação chama novamente a API antes de o tempo de espera terminar. Os openai-throttling presets e anthropic-throttling fazem o mesmo para os próprios erros de limite de taxa do fornecedor, e openai-throttling também devolve um credit_balance_exhausted 429 que não se deve tentar novamente.

Para outras APIs:

Também podes pedir ao teu agente de programação para escrever a configuração do Dev Proxy. Adiciona o servidor Dev Proxy MCP ao teu agente para que ele possa consultar a documentação e as melhores práticas do Dev Proxy e verificar que versão tens instalada. Reveja esta configuração como qualquer outro código que o agente escreva.

Para instalar Dev Proxy, consulte Configurar Dev Proxy.

Passos seguintes

Testa a minha aplicação com erros aleatórios

Ver também

  • Última atualização a