> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Colas FIFO y de mensajes no entregados

> Controle el orden, deduplique envíos y aísle mensajes que fallan repetidamente.

FIFO y el tratamiento de fallos resuelven problemas distintos. FIFO controla el siguiente mensaje que un grupo puede recibir. La redirección retira mensajes abandonados repetidamente de la cola original para investigarlos por separado.

<span id="fifo-groups" />

## Grupos FIFO

Una cola es FIFO cuando el nombre termina en `.fifo`. Cada envío exige `message_group_id`, de hasta 128 bytes. Use un grupo por flujo ordenado, como cliente o pedido. Los grupos distintos avanzan independientemente.

Un mensaje anterior no vencido bloquea los siguientes del grupo mientras esté concedido o retrasado. Un mensaje lento o con fallos repetidos puede bloquear todo el grupo. Confirmarlo, vencerlo o moverlo a la cola de fallos permite continuar.

<span id="deduplication" />

## Deduplicación

Los envíos FIFO exigen `message_deduplication_id`, de hasta 128 bytes, salvo con deduplicación por contenido. Reutilizar el mismo ID en la cola durante cinco minutos devuelve el ID del mensaje existente sin crear otro. El resultado indica duplicado.

En la deduplicación por contenido, un ID omitido se deriva del cuerpo. Los atributos no entran en el hash. Proporcione ID explícitos cuando cuerpos iguales representen eventos distintos. La deduplicación cubre envíos en la ventana; un consumidor aún puede recibir de nuevo tras vencer la concesión.

Un cuerpo de envío FIFO puede contener:

```json theme={null}
{
  "body": "{\"order_id\":\"A-1001\",\"status\":\"paid\"}",
  "message_group_id": "customer-42",
  "message_deduplication_id": "order-A-1001-paid"
}
```

<span id="dead-letter-queues" />

## Colas de mensajes no entregados

Cree el destino antes de vincularlo. Debe estar en la misma cuenta y región, tener el mismo tipo y ser distinto de la cola de origen. Elija una retención suficiente para investigar.

Defina los dos campos de redirección en la cola de origen:

```json theme={null}
{
  "redrive_policy": {
    "dead_letter_queue": "failed-orders.fifo",
    "max_receive_count": 5
  }
}
```

El destino acepta nombre, UUID o CRN en las solicitudes y se devuelve como referencia. El recuento mide concesiones, no excepciones de la aplicación. Tras alcanzar el máximo y vencer la concesión activa, el mensaje puede moverse de forma asíncrona; no tiene que aparecer inmediatamente en el destino. El destino inicia una nueva retención desde el movimiento, con recuento reiniciado y sin concesión activa.

Un mensaje problemático bloquea su grupo FIFO hasta eliminarse, vencer o pasar a la cola de fallos. La redirección permite avanzar; evalúe si omitir ese evento es aceptable para el flujo.

<span id="investigate-and-recover" />

## Investigar y recuperar

Consuma o inspeccione la cola de fallos, corrija el consumidor o los datos y vuelva a publicar deliberadamente lo que desee procesar. Un nuevo envío crea otro mensaje; conserve su ID de evento para idempotencia. No vuelva a publicar todos los fallos automáticamente en un ciclo.

Elimine la política con `redrive_policy: null` en el PATCH del origen. Esto no devuelve los mensajes existentes en el destino. La consola muestra las colas que referencian un destino para retirar sus vinculaciones antes de eliminarlo.

Una suscripción de Notifications también puede usar una cola para entregas fallidas. Esa política cubre intentos del servicio de alcanzar un destino; la política de la cola cubre fallos del consumidor al confirmar la concesión. Consulte [fallos de notificación](/es/notifications/delivery#dead-letter-queues).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.