Ciclo de vida da mensagem

Status possíveis

Status	Significado
`NAO_PROCESSADA`	Recebida e persistida, ainda não enfileirada
`ENFILEIRADA`	Job criado no BullMQ, aguardando worker
`PROCESSANDO`	Worker executando a entrega neste momento
`PROCESSADA`	Entregue com sucesso
`AGUARDANDO_REENVIO`	Falhou e está no intervalo de backoff antes da próxima tentativa
`ERRO_ENTREGA`	Falha técnica após esgotar as tentativas (timeout, conexão, HTTP 5xx)
`ERRO_NEGOCIO`	O destino respondeu, mas a resposta bateu com uma regra de erro de negócio
`ERRO_COLETA`	Falha ao buscar o dado na fonte externa (etapa 1 de uma Coleta)
`CANCELADA`	Descartada manualmente pela tela de cancelamento

ERRO_COLETA e ERRO_ENTREGA são coisas diferentes numa Coleta: o primeiro é falha ao ler a origem; o segundo, falha ao encaminhar para o destino um dado que já foi lido com sucesso.

Erro técnico × erro de negócio

Erro técnico — o destino não respondeu, estourou timeout ou devolveu erro de transporte. O CMS repete conforme as tentativas e o backoff da Definição.
Erro de negócio — o destino respondeu normalmente (HTTP 200, inclusive), mas o conteúdo da resposta casa com um padrão cadastrado em Erros de Negócio. Repetir não adianta: alguém precisa corrigir o dado. Opcionalmente a regra bloqueia a Interface, segurando as próximas mensagens até intervenção.

Onde as tentativas acontecem

O Máximo de tentativas da Definição vale nos dois modos de entrega, mas em lugares diferentes:

Modo	Onde repete	Intervalo entre tentativas
Assíncrona	No job da fila, fora da requisição de recebimento	10 segundos
Síncrona	Dentro da própria requisição de recebimento	1 segundo

O intervalo curto do modo síncrono é proposital: ali quem enviou a mensagem está esperando a resposta, e cada volta a mais é latência somada. Serve para atravessar uma falha momentânea — uma conexão recusada, o 502 de um proxy reiniciando — e não para aguardar um destino voltar do zero. Esse é o caso de uso da entrega assíncrona.

Em qualquer dos modos, o laço para antes de esgotar as tentativas quando:

a entrega dá certo;
o destino devolve um erro de negócio — repetir devolveria exatamente o mesmo erro;
a Aplicação de destino está offline no keep-alive — nem a primeira tentativa sai.

Cada tentativa grava seu próprio registro de processamento: é esse histórico que o detalhe da mensagem mostra.

Reprocesso

Mensagens em ERRO_ENTREGA ou ERRO_NEGOCIO podem ser reenviadas pela tela Erros de Entrega (/messages/delivery-errors), individualmente ou em lote. O reprocesso cria uma nova tentativa registrada no histórico da mensagem — nada é sobrescrito.

Retenção

O job de limpeza (módulo limpeza, configurável em Agendadores) roda toda madrugada e expurga mensagens antigas conforme os dias de retenção definidos em cada Interface — a retenção é por Interface, não global. O relatório de Armazenamento mostra o volume acumulado por Aplicação → Interface → Definição, com a retenção de cada uma ao lado.