¿Podemos reintentar una automatización sin duplicar tareas o mensajes?

Agotar el tiempo de espera significa que quien hizo la petición dejó de esperar; no demuestra que el receptor dejara de trabajar. Un reintento técnico no debe convertirse automáticamente en otra tarea, cupón o mensaje. Mejorar las instrucciones de la IA tampoco evita duplicados externos.

Acordar qué identifica una acción y qué registra cada intento

Un webhook es una notificación automática de un evento. Shopify advierte que puede entregarse más de una vez. Además, distintas suscripciones pueden notificar la misma acción del comerciante con identificadores de webhook diferentes. El identificador de entrega ayuda, pero no siempre identifica la operación de negocio. Tampoco conviene agrupar acciones distintas que sí son legítimas.

Asigna a cada operación un identificador estable que no contenga datos personales del cliente. Conserva ese identificador al reintentar y crea otro para cada intento técnico. Una acción nueva requiere identidad y aprobación propias, tras resolver cualquier operación anterior incierta.

Pide un registro persistente con el identificador de operación, evento y origen, acción prevista, datos aprobados y su versión, estado, número de intentos, referencia del destino, fechas y horas, responsable y siguiente decisión. Este registro de ejemplo no necesita datos sensibles del cliente.

Resolver el silencio del CRM antes de volver a enviar

Este ejemplo es ficticio y no se ha ejecutado: una solicitud de campaña debe crear una tarea de seguimiento en el CRM y después enviar un correo aprobado. El CRM guarda la tarea, pero su respuesta se pierde. Repetir todo el proceso podría crear una segunda tarea.

Busca la tarea mediante una referencia fiable. Si existe y corresponde a la operación, registra su identificador en el destino y comprueba por separado el correo. Que el servicio acepte la solicitud de envío no demuestra que el correo se haya entregado. Continúa desde la etapa pendiente. Sin confirmación ni reintento protegido documentado, deja la operación en espera para su responsable.

Como ejemplo concreto, los puntos de acceso de acciones personalizadas de Shopify Flow esperan hasta diez segundos una respuesta, cierran la conexión y vuelven a enviar más tarde. El campo action_run_id permite reconocer una misma ejecución, pero no evita automáticamente que el receptor duplique su trabajo. Ese plazo no es una regla general para CRM, webhooks o herramientas de IA.

Exigir protección también cuando dos intentos coinciden

Consultar un indicador local de «completado» no basta. Dos procesos simultáneos pueden comprobarlo antes de que ninguno lo actualice. Además, una acción externa puede terminar justo antes de que falle el guardado local del éxito. Solicita una reserva atómica —una única reserva indivisible— o una restricción de unicidad local, junto con protección en el destino o comprobación de sus resultados. Anotar el identificador o registrar el éxito después de actuar no ofrece por sí solo una garantía.

La idempotencia permite repetir la misma operación prevista sin añadir otro efecto, dentro de las condiciones documentadas del sistema. Comprueba acciones admitidas, duración y errores. El reintento protegido documentado conserva clave y parámetros aprobados dentro del plazo válido.

Stripe sirve de referencia técnica, sin plantear aquí automatizaciones de pagos. En las peticiones POST compatibles, la misma clave devuelve el primer estado y el primer cuerpo de respuesta guardados, incluidos los errores. Cambiar parámetros provoca un error. Las claves pueden eliminarse tras al menos 24 horas; reutilizarlas después crea una petición nueva. El resultado se guarda cuando comienza la ejecución del endpoint; los fallos de validación y conflictos simultáneos tienen otras reglas. Son condiciones de Stripe, no de cualquier integración.

Si el destino no permite confirmar el resultado ni impedir duplicados, la recuperación automática debe detenerse y pasar a revisión.

Conservar el contenido aprobado y recuperar cada etapa

La aprobación humana tampoco elimina el riesgo de repetición. Al reanudar después de una pausa activada con interrupt(), LangGraph ejecuta desde el principio el nodo, es decir, la etapa afectada; los cambios externos realizados antes de la pausa pueden repetirse. Su documentación recomienda operaciones idempotentes o separar o mover esos cambios. Separar etapas ayuda, aunque no cubre todos los fallos posteriores.

Guarda pruebas independientes de la tarea CRM y del envío del correo. Repite solo la etapa sin resolver, conforme a las reglas de recuperación, y conserva los datos y el contenido aprobados. Si vuelves a generar una respuesta del modelo, el texto puede cambiar: necesita otra revisión. La IA puede preparar borradores o clasificar errores, mientras que las acciones con consecuencias deben seguir reglas fijas, independientes del criterio del modelo, y tener un responsable humano.

Convertir las dudas en criterios de aceptación

Acuerda estos casos ilustrativos antes de habilitar la recuperación automática. Son criterios propuestos, no pruebas realizadas ni una certificación de ejecución única.

1. Ejecución normal: confirmar la acción externa prevista y guardar su referencia.
2. Evento duplicado: reutilizar pruebas y producir una sola acción prevista en los casos protegidos.
3. Espera agotada tras un éxito externo: recuperar el resultado o mantenerlo pendiente de revisión.
4. Dos intentos simultáneos: obtener una sola acción en el caso protegido mediante controles locales y externos.
5. Reanudación tras aprobar: conservar el contenido validado y no repetir las etapas completadas.
6. Repetición fuera del plazo de conservación: volver a comprobar el resultado o detenerse, sin asumir que sigue habiendo protección.

Mide por separado eventos, intentos, efectos externos confirmados y operaciones sin resolver, además del tiempo que dedica el operador a recuperar el proceso. Limita los reintentos y aumenta sus intervalos según la política documentada de cada destino; no uses un número universal ni reintentos infinitos.

Empezar con un proceso de alcance definido

El servicio de automatización de MindVerve define desencadenantes, entradas, salidas, responsables, reglas ante datos ausentes y fallos, pruebas e instrucciones operativas. AI Workflow Launch configura un proceso acordado: selección de herramientas, pruebas representativas y de fallos, guías o instrucciones reutilizables, documentación, formación y entrega. Se excluyen licencias, consumo de API e integraciones adicionales; el mantenimiento continuo se contrata aparte.