Envío y recuperación: el paso final y lo que viene después

Todos los pasos anteriores del asistente comparten una propiedad tranquilizadora: no hacen nada. Recogen, validan, ramifican y guardan en memoria, pero el mundo exterior sigue igual y por eso se puede ir y volver sin consecuencias. El último paso rompe esa propiedad de golpe. Al pulsar confirmar se crea un pedido, se cobra una tarjeta, se firma un contrato o se envía una solicitud que alguien leerá, y a partir de ese instante deshacer ya no es navegar sino compensar. Esa asimetría explica por qué el envío no es un paso más con un actor invocado dentro: es una frontera, y todo lo que la rodea —que no se pueda cruzar dos veces, que no se pueda volver, que se pueda averiguar qué pasó cuando la red se calló— son propiedades que hay que declarar, porque ninguna se cumple sola.

El punto de no retorno

La forma del final es siempre la misma: un estado que ejecuta, un estado final que devuelve la salida, y un estado de fallo que ofrece camino. Lo interesante no está en los tres nodos sino en las aristas que deliberadamente no se dibujan.

revision: {
  entry: 'asegurarClaveIdempotencia',
  on: { CONFIRMAR: 'enviando', ATRAS: 'pago.hist' },
},
enviando: {
  invoke: {
    src: 'enviarAlta',
    input: ({ context }) => ({ datos: context.datos, clave: context.clave }),
    onDone: { target: 'completado', actions: 'guardarRecibo' },
    onError: [
      { target: 'incierto', guard: 'fueTiempoDeEspera' },
      { target: 'fallido', actions: 'guardarError' },
    ],
  },
},
fallido: { on: { REINTENTAR: 'enviando', CANCELAR: 'abandonado' } },
completado: { type: 'final', output: ({ context }) => ({ recibo: context.recibo }) },

Desde enviando no sale ninguna arista de retroceso ni ninguna que responda a CONFIRMAR, y esas dos ausencias son las que hacen el trabajo. La primera declara que la revisión era el último sitio gratuito del flujo. La segunda elimina el doble envío sin una sola línea dedicada a ello: mientras la máquina esté enviando, un segundo clic produce un evento que ningún estado activo maneja, y un evento no manejado simplemente se descarta. La bandera de envío en curso que casi todo formulario del mundo mantiene a mano deja de existir, no porque se haya escondido mejor, sino porque la información que representaba ya está en la posición del grafo.

El tercer desenlace

La estructura anterior asume dos resultados, y por eso todavía es ingenua. Una petición que falla con error del servidor es un fracaso conocido: no ocurrió nada y reintentar es seguro. Una petición que expira sin respuesta no es eso en absoluto: el mensaje pudo llegar y ejecutarse, y lo único que se perdió fue la confirmación de vuelta. Tratar ambos casos con el mismo estado es la causa del cobro duplicado, y también de su contrario, el pedido perdido que el usuario creyó fallido y nunca volvió a intentar.

El tipo que describe esto es exito \| fallo \| desconocido, y el tercer habitante exige un estado propio que no envía nada sino que consulta. La consulta usa la misma clave de idempotencia como identificador de la operación, y su respuesta desambigua el limbo: si el servidor conoce esa clave, la operación se completó y el asistente termina como si nunca hubiera habido incidente; si no la conoce, no llegó a ejecutarse y reintentar vuelve a ser seguro.

incierto: {
  invoke: {
    src: 'consultarPorClave',
    input: ({ context }) => ({ clave: context.clave }),
    onDone: [
      { target: 'completado', guard: ({ event }) => event.output.existe, actions: 'guardarRecibo' },
      { target: 'enviando' },
    ],
    onError: { target: 'incierto', reenter: true },
  },
  after: { 3000: { target: 'irresoluble' } },
},

Ese estado es el que separa un asistente serio de una demostración. Requiere que el servidor ofrezca una consulta por clave, y si no la ofrece, la conversación correcta no es con la máquina sino con quien diseñó la interfaz remota: sin esa consulta, ningún cliente puede distinguir el limbo, y la única salida honesta es no reintentar automáticamente y llevar al usuario a una pantalla que le diga que revise su historial antes de volver a intentarlo.

stateDiagram-v2
revision --> enviando: CONFIRMAR
enviando --> completado: recibo
enviando --> fallido: rechazo explicito
enviando --> incierto: expira la espera
incierto --> completado: la clave ya existe
incierto --> enviando: la clave no existe
incierto --> irresoluble: no se pudo consultar
fallido --> enviando: REINTENTAR
fallido --> abandonado: CANCELAR
completado --> [*]

Guardar el progreso para retomarlo

Un asistente largo se abandona a la mitad por motivos que no son culpa de nadie: la pestaña se cierra, la batería se agota, alguien llama. Retomarlo exige persistir el actor, y la librería lo ofrece de forma directa: el actor sabe serializar su instantánea completa y se puede crear uno nuevo restaurándola. Lo difícil no es la mecánica sino las tres decisiones que la rodean.

const guardado = localStorage.getItem('alta')
const actor = createActor(alta, {
  snapshot: guardado ? sanear(JSON.parse(guardado)) : undefined,
})
actor.subscribe(() => {
  localStorage.setItem('alta', JSON.stringify(actor.getPersistedSnapshot()))
})
actor.start()

La primera decisión es qué no se guarda. Una instantánea tomada mientras había un actor invocado en vuelo describe una situación que no se puede reconstruir: al rehidratar no hay ninguna petición viajando, aunque el estado diga que sí. Lo mismo ocurre con los estados de error transitorios y con las esperas temporizadas, que reanudan su cuenta desde cero. La función que sanea antes de restaurar debe reescribir esas posiciones a un lugar seguro, y en un asistente el lugar seguro es casi siempre la revisión o, si el envío estaba en curso, el estado que consulta por clave: exactamente el mismo mecanismo que resolvía el limbo sirve para resolver la sesión interrumpida.

La segunda decisión es qué no debe tocar el almacenamiento local jamás. Un número de tarjeta completo, un documento de identidad o un código de verificación no se guardan aunque el usuario agradezca la comodidad, y la política limpia es marcar esos campos como volátiles y excluirlos de la serialización, aceptando que al retomar habrá que volver a pedirlos.

La tercera es dónde vive el borrador. El almacenamiento del navegador es inmediato y gratis, pero muere con el dispositivo y con el modo privado; guardar el progreso en el servidor permite empezar en el móvil y terminar en el escritorio, a costa de convertir el borrador en un recurso con dueño, con caducidad y con derecho al olvido. La elección no es técnica sino de producto, y casi siempre la respuesta correcta es la mixta: local en cada cambio para no perder nada entre pulsaciones, remoto al completar cada paso para no perder nada entre dispositivos.