mirror of
https://github.com/melgarafael/DeskcommCRM.git
synced 2026-10-02 01:28:34 +08:00
Elias GervannoandClaude Opus 5.5
4d90532ed7
A ingestão do webhook WAHA engolia a falha do banco nos quatro pontos em que a mensagem depende de uma escrita (contato, conversa, mensagem recebida e mensagem enviada pelo celular): `console.error` + `return`, e a rota devolvia 200. O WAHA riscava o evento achando que entregou, e a mensagem do cliente sumia — medido em produção: três perdidas em 14/09 num dia de `statement timeout`, duas na troca de banco de 24/09. - `lib/waha/falha-transitoria.ts`: a régua. Erro de dado, integridade, schema, regra de negócio e pedido malformado são permanentes; o resto (timeout, conexão, PostgREST sem banco, 5xx, sem código) é transitório. A ingestão passa a lançar a classe certa nos quatro pontos. - `lib/waha/desfecho-do-webhook.ts`: as duas rotas gravam o desfecho no arquivo (`processed` / `error`), que até aqui nascia e morria `received`. Falha transitória responde 503 + Retry-After: o WAHA reentrega qualquer erro 15x com espera max(2s, Retry-After), e a reentrega é segura porque o 23505 vira dedup. - `app/api/v1/cron/webhook-replay`: relê a cada minuto o arquivo marcado `transitoria:`, até 20 tentativas; depois `dead` e um aviso `event_dead` na Central com título próprio (`MENSAGEM_QUE_NAO_ENTROU`), que o dreno de handlers exclui do seu dedupe. Para na terceira falha seguida da rodada para não martelar um banco que ainda está voltando. É o `process-pending-webhooks` que o PRD 03 e a Spec 03 prometiam; os dois passam a dizer o nome e a régua reais. Sem migration: `processed` e `dead` já estavam no CHECK, `event_dead` já existia. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>