Cómo evitar acciones duplicadas cuando una automatización reintenta
Una guía práctica con laboratorio para entender solicitudes repetidas, confirmaciones perdidas y cambios que requieren otra decisión.
Probar la herramienta
Conservá la identidad de la operación, distinguí un resultado incierto de un fallo y comprobá lo ocurrido antes de autorizar otra acción.
Más intentos. ¿Más acciones?
Probá una solicitud ficticia para preparar 2 unidades de un pedido. Compará lo que sabe quien envía con lo que ocurrió en el destino.
- Clave de la operación
- DEMO-OP-017
- Referencia ficticia
- DEMO-ORDER-017
- Primera solicitud → reintento
- 2 → 2 unidades
Listo para probar
Enviá la primera solicitud y observá los dos contadores.
Confirmación disponible: Todavía no disponible
0 intentos; 0 acciones ficticias; 0 verificaciones.Nombrá la acción que no conviene repetir
Empezá por una acción concreta: agregar un pedido, enviar un aviso o crear una tarea de entrega. Anotá dónde se ve su resultado y quién detectaría un duplicado. Un flujo puede terminar correctamente y aun así producir una fila extra.
El ejemplo sintético es un taller ficticio que prepara dos unidades para el pedido DEMO-ORDER-017. El simulador no envía solicitudes de red ni crea pedidos reales. Permite observar por separado las solicitudes intentadas y las acciones realizadas en un destino ficticio.
Elegí el escenario normal. Enviá una solicitud y repetila: dos intentos y una acción. Pedile a quien realiza la tarea que identifique la confirmación original y explique dónde aparecería un caso pendiente.
Conservá la identidad de la operación
Asigná una referencia cuando el equipo decide realizar la acción. Conservála durante reintentos, reinicios y cambios de responsable. Una referencia aleatoria nueva por intento hace que una operación anterior parezca nueva. Delimitá las referencias por cuenta y operación: reutilizar una etiqueta para trabajos distintos impide entender qué se autorizó.
Stripe documenta un contrato concreto: repetir una solicitud con la misma clave de idempotencia permite recuperar su resultado guardado; cambiar sus parámetros se rechaza. Sus reglas de conservación y ejecución importan. Comprobá el contrato vigente del endpoint que uses.
Elegí ahora el escenario con datos cambiados. La primera solicitud pide dos unidades y el reintento pide tres con la misma referencia. El simulador rechaza el cambio y conserva la acción original. Corregir un pedido necesita una decisión explícita. Otro pedido autorizado puede tener contenido idéntico y seguir siendo una operación distinta.
Mantené visible una confirmación pendiente
Elegí el escenario de respuesta perdida y enviá una vez. El destino cuenta una acción, pero quien envía no tiene confirmación. El simulador muestra ambas perspectivas porque controla todo el ejercicio ficticio. En un sistema real, quien envía necesitaría evidencia del destino para afirmar que la acción ocurrió.
El patrón Retry de Azure explica el riesgo de repetir una operación completada cuando se pierde su respuesta. También recomienda adaptar los reintentos al fallo, con esperas adecuadas e intentos limitados. Un timeout por sí solo no demuestra que nada cambió.
Presioná reintentar. Este modelo retiene la solicitud sin agregar otra acción. Usá verificar para consultar el registro ficticio y volvé a reintentar: ahora la confirmación es reutilizable. En un flujo real, asigná los casos inciertos a alguien que pueda consultar el proveedor o sistema de referencia. Anotá la operación, la evidencia disponible y la siguiente comprobación. Una búsqueda vacía tampoco siempre demuestra ausencia, especialmente cuando los registros tardan en aparecer.
Separá la notificación de la acción
Algunas automatizaciones empiezan con un webhook: un servicio avisa que algo ocurrió. Recibir otra vez ese aviso no autoriza automáticamente otra entrega, mensaje o fila de Excel.
La guía de webhooks de Stripe distingue la entrega repetida de un evento de otros eventos que afectan al mismo objeto y tipo de evento. También advierte que pueden llegar desordenados. Son hechos específicos del proveedor que conviene considerar al definir qué reconoce tu integración como duplicado.
Para ensayar el caso del taller, prepará dos avisos ficticios sobre la misma solicitud. Pedile a quien opera que encuentre la operación existente antes de decidir el siguiente paso. Después agregá una corrección legítima. ¿El proceso conserva el cambio o lo descarta porque ya había visto el pedido? Separá autenticación, cambios de estado válidos y control de duplicados: reconocer una referencia conocida no demuestra que el mensaje esté autorizado.
Explicá qué necesita un sistema real
El modelo del navegador olvida todo al reiniciar o recargar. Trabaja secuencialmente en memoria; no demuestra recuperación después de una caída del servidor ni ante dos procesos simultáneos. Una demostración correcta explica un comportamiento, pero no acredita esas garantías en una integración real.
En producción, necesitás registros durables y una reserva única atómica antes de que dos procesos reclamen la misma operación. Consultar y después insertar por separado deja una carrera. AWS explica por qué registrar la clave y los cambios asociados requiere un límite atómico cuando el servicio controla esas modificaciones.
Una acción externa todavía puede completarse antes de guardar su confirmación local. Usá la idempotencia que admita el proveedor y conciliá resultados ambiguos contra sus registros. Una reserva local no incorpora otro servicio a tu transacción. Pedile a quien implementa que muestre qué sucede en ese límite, cuánto tiempo sirven las referencias y quién atiende los casos que no se pueden resolver automáticamente.
Probá las dificultades antes de ampliar el flujo
Descargá el CSV bilingüe junto al simulador. Los casos interactivos indican los contadores esperados. Las filas de revisión para producción describen comprobaciones que este navegador no puede realizar.
Ensayá los tres escenarios con quien realiza la tarea. Pedile que anticipe cada resultado. Registrá los desacuerdos como decisiones pendientes. Determinar si una corrección reemplaza una solicitud anterior pertenece al proceso del negocio; el mecanismo de reintentos no debería inventar esa política.
Antes de un piloto real, probá interrupciones, evidencia no disponible y procesos simultáneos en un entorno de pruebas aislado. Compará intentos, operaciones confirmadas y casos pendientes. Evitá guardar mensajes completos de clientes o credenciales en registros de diagnóstico. Asigná responsable y momento de revisión al trabajo pendiente. Ampliá el flujo cuando el equipo pueda explicar un resultado inesperado, encontrar su evidencia y recuperarse sin repetir la acción a ciegas.
Llevá la pregunta a tu equipo.
Tres preguntas para explorar juntos. Abrí una y usala como punto de partida.
01¿Qué acción de tu flujo sería más costosa de repetir y dónde podrías comprobar su resultado?
Anotá una situación concreta, escuchá otra perspectiva y acordá un pequeño próximo paso. Si querés una mirada externa, podemos conversarlo.
Conversar con el estudio02¿Quién puede decidir si una operación incierta debe esperar, corregirse o intentarse otra vez?
Anotá una situación concreta, escuchá otra perspectiva y acordá un pequeño próximo paso. Si querés una mirada externa, podemos conversarlo.
Conversar con el estudio03¿Qué prueba mostraría la recuperación si el destino completa la acción, pero se pierde la confirmación?
Anotá una situación concreta, escuchá otra perspectiva y acordá un pequeño próximo paso. Si querés una mirada externa, podemos conversarlo.
Conversar con el estudioPara seguir explorando
Referencias públicas que amplían estas ideas.
¿Cómo se ve esto en tu negocio?
Empecemos con una conversación de 30 minutos, sin costo, sobre tu objetivo y tus prioridades.
Contanos tu idea
Guía + herramienta