¿Qué pasa cuando un flujo se ejecuta dos veces o falla a la mitad?

Un reintento necesita saber qué ya pasó.

Una consulta puede llegar dos veces. Una persona puede aprobar dos veces. Una conexión puede fallar cuando ya se ejecutó parte de un flujo. Son situaciones distintas: antes de repetir cualquier cosa, identifica la solicitud, la acción prevista y la evidencia de su resultado.

El ejemplo conserva el registro y vuelve a preguntar.

En la demo del navegador, reinicia y ejecuta “Trabajo nuevo”. Marca “Simular una conexión fallida en esta aprobación” y luego “Aprobar la respuesta de la demo”. Revisa “Conexión en pausa” y su historial. Selecciona “Restablecer la conexión de ejemplo”, vuelve a revisar el texto y aprueba. El botón de restaurar desmarca la casilla de falla para que la siguiente aprobación pueda terminar el ejemplo.

¿Qué se conserva y qué no se puede repetir?

La información que falta sigue faltando después de restaurar. Si una consulta incompleta se aprueba después de la recuperación, vuelve a “Esperando datos”. Un reintento no inventa un área, no confirma una cita ni recibe la respuesta de un cliente.

Una falla parcial real es más difícil.

Imagina que un flujo conectado actualiza el registro de un trabajo y luego pierde la confirmación antes de registrar el éxito localmente. Su estado local puede ser incierto aunque el destino sí haya cambiado. Repetir todo el flujo podría repetir un efecto externo.

Es un caso hipotético de producción; el ejemplo de Fireflax no lo simula. Una implementación real necesita identificadores duraderos para las solicitudes y las acciones previstas, un registro guardado de los resultados, revisiones del destino y una regla para los resultados inciertos. La memoria del navegador y que coincida el texto del mensaje no bastan.

El kit inicial sin conexión conserva un archivo local y ofrece un comando de pausa explícito, pero sigue siendo un ensayo de un solo proceso. No confirma reintentos concurrentes seguros, entrega exactamente una vez, disponibilidad en producción ni reversión entre sistemas.

Usa esta lista de verificación de recuperación.

1. Pausa y conserva. Detén el flujo correspondiente con el procedimiento acordado. Conserva la solicitud, las versiones, el error y la evidencia del resultado.
2. Revisa el destino. Comprueba si el mensaje, el registro u otro cambio previsto ocurrió. Clasifícalo como hecho, no hecho o incierto.
3. Evita reenviar a ciegas. Resuelve la duda con la persona responsable y la evidencia del sistema. Revisa los identificadores de la solicitud y de la acción, y la regla de duplicados.
4. Restaura con el responsable de los permisos. Arregla o vuelve a autorizar la conexión real según haga falta. Restaurar el acceso no autoriza repetir todas las acciones.
5. Revisa de nuevo. Vuelve a revisar la solicitud más reciente y cualquier cambio en la conversación, el borrador o la preferencia de contacto. Obtén una nueva aprobación donde se requiera.
6. Verifica un solo resultado previsto. Realiza solo el siguiente paso autorizado, revisa su resultado y registra qué pasó antes de retomar el trabajo normal.

Nombra al responsable y al respaldo de estos pasos. Un mensaje que ya se envió no se puede anular reiniciando un registro interno. Cualquier corrección o reversión necesita sus propios permisos y límites confirmados.

Guarda la evidencia junto con la entrega.

Las ejecuciones guardadas del código fuente y del kit inicial cubren cinco casos definidos cada una, incluidas la aprobación repetida y la aprobación fallida con recuperación. Registran datos sintéticos, estados exactos e historial. El conjunto aparte de 21 pruebas del repositorio también revisa la recuperación cuando falta información. Estas revisiones concretas respaldan las descripciones de arriba; no son una garantía de entrega.