Ciclo de vida del mensaje

Estados posibles

Estado	Significado
`NAO_PROCESSADA`	Recibida y persistida, todavía no encolada
`ENFILEIRADA`	Job creado en BullMQ, esperando worker
`PROCESSANDO`	Worker ejecutando la entrega en este momento
`PROCESSADA`	Entregada con éxito
`AGUARDANDO_REENVIO`	Falló y está en el intervalo de backoff antes del próximo intento
`ERRO_ENTREGA`	Falla técnica tras agotar los reintentos (timeout, conexión, HTTP 5xx)
`ERRO_NEGOCIO`	El destino respondió, pero la respuesta coincidió con una regla de error de negocio
`ERRO_COLETA`	Falla al buscar el dato en la fuente externa (etapa 1 de una Recolección)
`CANCELADA`	Descartada manualmente desde la pantalla de cancelación

Estos valores son identificadores literales de la API, no etiquetas de pantalla. Son cadenas en portugués del contrato y nunca se traducen — úsalos tal cual al filtrar (GET /mensagens?status=ERRO_ENTREGA) o al leer el cuerpo de una respuesta. La interfaz muestra una etiqueta traducida para cada uno, pero el valor almacenado y transportado no cambia con el idioma.

ERRO_COLETA y ERRO_ENTREGA son cosas distintas en una Recolección: el primero es una falla al leer el origen; el segundo, una falla al reenviar al destino un dato que ya fue leído con éxito.

Error técnico × error de negocio

Error técnico — el destino no respondió, se agotó el timeout o devolvió un error de transporte. El CMS reintenta según los intentos y el backoff de la Definición.
Error de negocio — el destino respondió normalmente (incluso HTTP 200), pero el contenido de la respuesta coincide con un patrón registrado en Errores de Negocio. Reintentar no sirve: alguien tiene que corregir el dato. Opcionalmente la regla bloquea la Interfaz, reteniendo los próximos mensajes hasta que haya intervención.

Dónde ocurren los intentos

El Máximo de intentos de la Definición vale en los dos modos de entrega, pero en lugares distintos:

Modo	Dónde repite	Intervalo entre intentos
Asíncrona	En el job de la cola, fuera de la solicitud de recepción	10 segundos
Síncrona	Dentro de la propia solicitud de recepción	1 segundo

El intervalo corto del modo síncrono es intencional: ahí quien envió el mensaje está esperando la respuesta, y cada vuelta de más es latencia sumada. Sirve para atravesar una falla momentánea — una conexión rechazada, el 502 de un proxy reiniciando — y no para aguardar que un destino vuelva desde cero. Ese es el caso de uso de la entrega asíncrona.

En cualquiera de los modos, el bucle se detiene antes de agotar los intentos cuando:

la entrega funciona;
el destino devuelve un error de negocio — repetir devolvería exactamente el mismo error;
la Aplicación de destino está offline en el keep-alive — ni el primer intento sale.

Cada intento graba su propio registro de procesamiento: ese historial es el que muestra el detalle del mensaje.

Reproceso

Los mensajes en ERRO_ENTREGA o ERRO_NEGOCIO pueden reenviarse desde la pantalla Errores de Entrega (/messages/delivery-errors), individualmente o en lote. El reproceso crea un nuevo intento registrado en el historial del mensaje — nada se sobrescribe.

Retención

El job de limpieza (módulo limpeza, configurable en Programadores) corre cada madrugada y purga mensajes antiguos según los días de retención definidos en cada Interfaz — la retención es por Interfaz, no global. El informe de Almacenamiento muestra el volumen acumulado por Aplicación → Interfaz → Definición, con la retención de cada una al lado.