Como verificar o tratamento de erros que seu agente de codificação escreveu

Seu agente de codificação diz que adicionou novas tentativas e tratamento de limite de taxa, e seus testes são aprovados. Antes de confiar nisso, verifique contra o que os testes foram executados.

Em um teste que executamos com 3 agentes de codificação (210 execuções), pedimos que eles fizessem aplicativos lidarem com falhas de API e mostrassem que eles funcionam. Em 76% das 140 execuções que pediram código funcional, o agente criou a falha manualmente com stubs de fetch, 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 excluiu, 0 execuções testaram o aplicativo em sua URL de API real. Passar em testes como esses prova que o código do agente lida com a falha que o agente imaginou. Essa é uma falha diferente daquela que a API envia.

Checklist

  1. Pergunte contra o que isso foi testado. Pergunte ao agente: "Qual URL o aplicativo chamou durante o teste e o que retornou o erro?" Se a resposta for um stub ou um servidor local que ele escreveu, trate os testes como testes de unidade dos branches adicionados.
  2. Procure interruptores adicionados para testes. Pesquise o diff por novas variáveis de ambiente, configurações de URL base ou sinalizadores. Em nosso teste, 61 das 105 execuções em aplicativos que chamam GitHub, OpenAI ou uma API meteorológica adicionaram uma chamada. Decida se deseja isso em produção.
  3. Verifique o código em relação ao comportamento documentado da API. Cada API falha à sua maneira:
    • GitHub: quando você excede o limite de taxa primária, obtém 403 ou 429 com x-ratelimit-remaining definido como 0, e você aguarda até o tempo em x-ratelimit-reset, em segundos de época UTC. Para limites de taxa secundários, aguarde retry-after se ele estiver lá, caso contrário, aguarde até x-ratelimit-reset se x-ratelimit-remaining estiver 0, caso contrário, pelo menos 1 minuto. O código que verifica apenas 429 perde os 403s.
    • OpenAI: alguns erros 429 são sobre limites de cobrança e gastos, como credit_balance_exhausted. Tentar isso novamente não vai adiantar. O código que tenta novamente sempre que recebe um erro 429 oculta o problema para você.
    • Anthropic: o status 429 de limite de gastos não tem o cabeçalho retry-after, e situações de sobrecarga retornam 529, algo que códigos que só conhecem códigos de status padrão podem não esperar.
  4. Verifique como fica Retry-After. O cabeçalho contém ou um número de segundos ou uma data HTTP (RFC 9110). Verifique se o código lida com o formato que sua API envia, limita o número de tentativas e o tempo total de espera, e não repete tentativas sobre um SDK que já as faz automaticamente.
  5. Verifique o que o usuário vê quando as tentativas se esgotam. Procure uma mensagem clara em vez de um stack trace ou de um spinner infinito e verifique se o usuário não perde seu trabalho.
  6. Execute o aplicativo em suas URLs reais com falhas simuladas. Esta é a única etapa que mostra como o aplicativo em execução, seu SDK e sua política de repetição funcionam em conjunto.

Como verificar o tratamento de erros escrito pelo agente

Approach O que você encontra Do que você sente falta
Leia as diferenças Se o código parece certo Se isso se comporta corretamente diante das respostas reais da API
Executar os testes do agente Que as ramificações que ele escreveu sejam executadas Tudo o que o stub não modelou: códigos de status reais, cabeçalhos, corpos de erro e tentativas do SDK
Chame a API real até que ela falhe Comportamento real Você não pode provocar falhas sob demanda, e você gasta sua cota real
Executar o aplicativo em URLs reais com falhas simuladas Como o aplicativo em execução, seu SDK e sua política de repetição lidam com os erros da própria API Seu código de forma isolada. Reserve os testes unitários do agente para isso.

Teste isso no seu aplicativo

Dev Proxy intercepta as solicitações que seu aplicativo envia à API real e retorna os erros escolhidos, sem alterações no código do aplicativo. Para APIs populares, comece com uma predefinição. Para verificar como seu agente lidou com o limite de taxa do GitHub, escreveu:

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

Execute seu aplicativo e observe a saída do Dev Proxy. A configuração predefinida retorna um 429 com os cabeçalhos de limite de taxa do GitHub depois que seu aplicativo ultrapassa o limite. O RetryAfterPlugin na predefinição informa se seu aplicativo chama a API novamente antes do tempo de espera acabar. As predefinições openai-throttling e anthropic-throttling fazem o mesmo para os erros de limite de taxa do próprio provedor, e openai-throttling também retorna um credit_balance_exhausted 429 que não deve ser tentado novamente.

Para outras APIs:

Você também pode pedir ao seu agente de código para escrever a configuração do Dev Proxy. Adicione o servidor MCP do Dev Proxy ao seu agente para que ele possa consultar a documentação e as práticas recomendadas do Dev Proxy e verificar qual versão você tem instalada. Examine essa configuração como qualquer outro código que o agente escreve.

Para instalar o Dev Proxy, consulte Configurar o Dev Proxy.

Próximas Etapas 

Teste meu aplicativo com erros aleatórios

Consulte também

  • Última atualização em