Las características de reintento de Eventarc coinciden con las de su capa de transporte, Cloud Pub/Sub. Para obtener más información, consulta Solicitudes de reintento y Retirada de envío.
La duración predeterminada de la retención de mensajes que establece Eventarc es de 24 horas con un retraso de retirada exponencial.
Puedes actualizar la política de reintento a través de la suscripción de Pub/Sub asociada con el activador de Eventarc:
- Abre la página Detalles del activador.
- Haz clic en el tema.
- Haz clic en la pestaña Suscripciones.
Cualquier suscripción
creada automáticamente por Eventarc tendrá este formato:
projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Para obtener más información sobre los límites
de suscripción, consulta
Límites de recursos de Pub/Sub.
Si Pub/Sub intenta entregar un mensaje, pero el destino no puede confirmar la recepción, Pub/Sub volverá a enviar el mensaje con una retirada exponencial mínima de 10 segundos. Si el destino continúa sin confirmar la recepción del mensaje, se agrega más tiempo a la demora en cada reintento (hasta un máximo de 600 segundos) y el mensaje se vuelve a enviar al destino.
Ten en cuenta que Workflows confirma los eventos apenas comienza la ejecución del flujo de trabajo.
Temas de mensajes no entregados
Si el destino no recibe el mensaje, puedes reenviar los mensajes no entregados a un tema de mensajes no entregados (también conocido como la cola de mensajes no entregados). Un tema de mensajes no entregados puede almacenar mensajes que el destino no puede confirmar. Debes establecer un tema de mensajes no entregados cuando crees o actualices una suscripción de Pub/Sub, no cuando crees un tema de Pub/Sub o cuando Eventarc cree un tema de Pub/Sub. Para obtener más información, consulta Controla las fallas de los mensajes.
Errores que no garantizan reintentos
Cuando las aplicaciones usan Pub/Sub como la fuente del evento y dicho evento no se entrega, se vuelve a intentar el evento de forma automática, excepto los errores que no garantizan reintentos. Los eventos al destino del flujo de trabajo desde cualquier fuente no se volverán a intentar si el flujo de trabajo no se ejecuta. Si se inicia la ejecución del flujo de trabajo, pero luego falla, no se reintentan las ejecuciones. Para resolver estos problemas de servicio, debes manejar los errores y los reintentos dentro del flujo de trabajo.
Eventos duplicados
Los eventos duplicados pueden entregarse a los controladores de eventos. Según la
especificación de CloudEvents,
la combinación de los atributos source y id se considera única y,
por lo tanto, cualquier evento con la misma combinación se considera duplicado.
Debes implementar controladores de eventos
idempotentes como práctica recomendada general.
Haz que los controladores de eventos sean idempotentes
Los controladores de eventos que se pueden reintentar deben ser idempotentes con los siguientes lineamientos generales:
- Muchas APIs externas te permiten proporcionar una clave de idempotencia como parámetro. Si usas una API de este tipo, debes usar el ID de evento como la clave de idempotencia.
- La idempotencia funciona bien con la entrega "al menos una vez", ya que permite que los reintentos sean seguros. Por lo tanto, una recomendación general para escribir un código confiable es combinar la idempotencia con los intentos reiterados.
- Asegúrate de que tu código sea idempotente de forma interna. Por ejemplo:
- Asegúrate de que puedan ocurrir mutaciones más de una vez sin que cambie el resultado.
- Consulta el estado de la base de datos en una transacción antes de mutar el estado.
- Asegúrate de que todos los efectos secundarios sean idempotentes en sí.
- Debes imponer una verificación transaccional fuera del servicio, sin importar el código. Por ejemplo, conserva el estado en algún lugar que registre si ya se procesó un ID de evento determinado.
- Administra las llamadas duplicadas fuera de banda. Por ejemplo, implementa un proceso de limpieza independiente que borre las llamadas duplicadas.