Dois clientes corrigiram, cada um, metade do mesmo bug de perda silenciosa. Um terceiro seguia com ele intacto. Isso virou padrão.
204 blindado · cascata de telefone · exceção nunca some · fila de retry · zero erro no deploy
Em junho escrevemos sobre 5 armadilhas da atribuição Meta Ads → CRM. Uma delas era o HTTP 204 que o Kommo devolve quando não encontra um lead — que vira exceção silenciosa se você chama .json() sem checar o status antes.
O que não contamos: dois clientes corrigiram esse bug de forma independente, cada um sem saber que o outro tinha o mesmo problema. Um blindou o parse do 204. O outro construiu uma busca por telefone com variantes e uma fila de reprocessamento. Nenhum dos dois tinha o pacote inteiro.
E um terceiro cliente — em produção todo santo dia desde abril — tinha o bug do 204 intacto, do jeito que ele nasceu. Ninguém tinha percebido. Achamos auditando o código real que estava rodando, não a documentação que dizia o que deveria estar rodando.
Em vez de corrigir o terceiro cliente e seguir em frente, paramos pra sintetizar as duas soluções parciais num pacote só — e aplicar esse pacote como padrão obrigatório em toda instância nova do PostepTrack.
A cascata de telefone existe porque o CRM às vezes indexa o contato num formato diferente do que a Meta manda: tenta o número cru, depois com “+”, depois só dígitos, depois a variante brasileira sem o 9º dígito do celular. Só dispara em caso de não-encontrado — o caminho feliz continua com uma chamada só.
A fila de reprocessamento é uma rota autenticada (?action=retry) chamada a cada 5 minutos por um schedule externo. Lead não encontrado na hora vira recovery_pending=true em vez de erro definitivo — e é retentado por até 1 hora antes de desistir de vez.
Aplicamos o v4 no cliente que estava em produção desde abril com o bug do 204 intacto. Regra que seguimos à risca: auditar o código real antes de tocar em qualquer coisa — não a documentação, o arquivo que está de fato deployado.
Depois do deploy, quatro checagens ao vivo — não só confiar na mensagem de “sucesso” do CLI: o endpoint responde ao desafio de verificação, token errado é recusado, a rota de retry sem segredo é bloqueada, a rota de retry com o segredo certo devolve o JSON esperado. E confirmação por fora, direto na API, de que a função nova estava mesmo no ar.
Resultado: zero erro pós-deploy. E nenhuma linha das particularidades do cliente foi tocada — duas gambiarras históricas de UTM e o roteamento de 9 números de WhatsApp em 4 contas diferentes continuaram exatamente como estavam.
Confiabilidade é ortogonal a regra de negócio. Se um cliente decidiu que utm_campaign pertence a outro sistema, ou que um número de WhatsApp específico roteia pra um time específico, isso não muda porque a gente melhorou o tratamento de erro por baixo.
Tem um caso na fila agora com uma complicação a mais: um cliente cujo evento de conversão pro Meta só dispara depois que o lead é encontrado no CRM — o que significa que ele nunca dispara pros leads que demoram a aparecer. Faz sentido técnico desacoplar os dois. Mas isso muda o volume de dado que alimenta a otimização de campanha ativa.
Então dividimos em duas fases: o hardening técnico sobe agora, sem mexer em uma vírgula do comportamento de negócio. A mudança que afeta dado de campanha fica registrada, medida antes de decidida, e só sobe com aprovação explícita — separada do deploy de confiabilidade.
Regra: se a mudança só torna o sistema mais confiável, ela é neutra e pode subir. Se ela também muda o que o sistema decide ou reporta, é uma decisão de negócio disfarçada de bug fix — e precisa ser tratada como tal.
o mesmo bug de perda silenciosa (HTTP 204 mal tratado) foi corrigido do zero em dois clientes diferentes, e continuava intacto num terceiro quatro meses depois.
as duas soluções parciais viraram um pacote único de 4 peças: 204 blindado, cascata de telefone, exceção sempre registrada, fila de reprocessamento automático.
auditoria do código real (não da doc), migração aditiva, fusão cirúrgica, deploy só via CLI, 4 checagens ao vivo. Zero erro pós-deploy.
nenhuma regra de negócio do cliente foi tocada. Hardening é ortogonal à decisão — nunca vira desculpa pra uniformizar à força.
Um bug corrigido duas vezes em dois lugares diferentes não é azar — é sinal de que falta um padrão. A lição vira post; o padrão vira código que todo cliente novo já nasce com ele.