Pegando o agente no erro: falhas de um refactor de verdade

O trabalho

O serviço gera comprovantes de exibição: para um pedido de mídia, um PDF e planilhas dizendo o que passou, onde e quando, lidos do ClickHouse. Reescrevi com o agente entre 27 de agosto e 4 de setembro. A versão nova rodou em paralelo no mesmo servidor, em /v2/, com a antiga como referência, e virou a oficial nos primeiros dias de setembro. A regra nesse período era simples: push pode, pull request não, nada vai para o ar antes de terminar.

A maior parte do código foi digitada pelo agente; eu dirigi, revisei e rodei. Abaixo estão os erros dele que chegaram a um commit ou a uma tela, nas palavras do próprio agente quando ele os escreveu numa mensagem de commit.

O teto de 15.000 linhas

PDFs grandes estavam morrendo. Um pedido com 32.958 linhas rodava 12 minutos e 52 segundos e terminava em Allowed memory size exhausted, com HTTP 200. Em 28 de agosto o agente resolveu recusando tudo acima de 15.000 linhas, com 413 e uma mensagem. O raciocínio parecia bom: a biblioteca de PDF gastava de 131 a 137 KB por linha, então com 2,5 GB o limite real ficava perto de 19.000 linhas, e 15.000 ficava abaixo.

Em 31 de agosto abri um pedido real com 17.394 linhas no deploy paralelo, e ele foi recusado. Isso não deveria acontecer. O sistema antigo já gerava os grandes em segundo plano, com a página consultando o progresso, e eu sabia de uso que funcionava. O commit seguinte diz com todas as letras: "Meu teto de 15.000 recusava antes de ela começar." Com o cliente cortado aos 120 segundos pela CDN na frente, a geração em segundo plano continuou até o PDF ficar pronto, com 1,88 MB.

O que importava era o lock, e a contagem de linhas era só um indicador dele. A geração segura um lock com TTL de 900 segundos, e depois disso uma segunda requisição começa a gerar o mesmo PDF em paralelo: dois processos de 2,5 GB disputando o mesmo arquivo. A partir do ponto medido, 17.394 linhas em 570 segundos e uma curva perto de n^1,75, o teto foi para 20.000 linhas, o que deixa 170 segundos de folga para máquina carregada. O agente otimizou para o que via no código. Eu sabia como o sistema antigo se comportava em produção, e todos os testes passavam com o teto errado.

Um try/catch que não pega nada

Aquele teto veio depois de outro erro. Um commit anterior dizia que um try/catch resolvia o lock órfão quando a geração morria. Não resolvia, e o commit seguinte do agente começa com "Estava errado, e o erro era meu". Estourar a memória ou o max_execution_time é erro fatal no PHP, e erro fatal não é Throwable:

<?php
// php -d memory_limit=32M oom.php
try {
    $a = [];
    while (true) { $a[] = str_repeat('x', 1024 * 1024); }
} catch (\Throwable $e) {
    echo "caught\n";     // nunca imprime
} finally {
    echo "finally\n";    // também nunca imprime
}

Nem uma shutdown function ajudou, porque o handler de exceção do framework chama exit() antes. Forçamos um OOM com 64 MB para confirmar. Depois de um erro fatal não sobra nada para limpar, então a única saída é não chegar lá: contar as linhas antes e mandar os grandes para o caminho em segundo plano.

Um spinner que baixava HTML como PDF

Pedi um spinner enquanto os documentos são gerados, e o agente trocou um simples por fetch com blob para ligar e desligar o spinner. Só que a mesma rota devolve um PDF quando o documento cabe e uma página HTML com opções quando não cabe, e agora qualquer resposta era salva como .pdf. O link antigo funcionava por acidente: o navegador simplesmente mostrava a página. Esse chegou à produção e ficou um dia. Commit: "Regressão minha". A correção agora olha o Content-Type e, quando não é PDF, deixa o navegador navegar como o link fazia antes:

const res = await fetch(url);
const type = res.headers.get("Content-Type") || "";
if (!type.startsWith("application/pdf")) {
  res.body?.cancel();
  window.location.href = url;   // faz o que o link fazia
  return;
}
saveAs(await res.blob(), filename);

• engenharia com ia
• agentes de ia
• code review
• guardrails
• verificação
• refatoração