Workflows: procesos durables que sobreviven al fallo

Un fetch es una chispa: se enciende, atiende una petición, responde y se apaga. Es perfecto para request/response, pero desastroso para un proceso largo. Piensa en un pedido: cobrar la tarjeta, aprovisionar el servicio, enviar la confirmación, esperar tres días, hacer seguimiento. Si el isolate se recicla o el paso tres falla, todo el estado en memoria se evapora, y no querrás volver a cobrar la tarjeta al reintentar. Los Workflows resuelven esto con una idea profunda —la ejecución durable—: escribes código lineal y corriente, y la plataforma guarda tu progreso después de cada paso, de manera que el proceso puede morir entre dos pasos y renacer justo donde estaba.

El problema: la ejecución efímera

Un manejador de peticiones vive lo que dura una respuesta. Esa brevedad es una virtud cuando el trabajo empieza y acaba en la misma invocación, pero se vuelve una trampa cuando el proceso se extiende en pasos y en tiempo. Un pedido que cobra, aprovisiona, notifica y espera días no cabe en una sola chispa: en algún punto el isolate se recicla, se despliega una versión nueva o un paso lanza una excepción, y el estado en memoria desaparece con él.

Para hacer ese proceso fiable a mano tienes que construir siempre la misma fontanería. Externalizar cada estado intermedio a una base de datos. Hacer idempotente cada paso, para que un reintento no cobre dos veces. Levantar una máquina de estados que sepa por dónde iba el proceso. Y un planificador que lo despierte y lo reanude. Es mucho código, es el mismo código una y otra vez, y es sutilmente difícil: justo en la ventana entre “ejecuté el efecto” y “anoté que lo ejecuté” es donde anidan los peores errores.

Qué es la ejecución durable

Un Workflow es un motor de ejecución durable. Extiendes WorkflowEntrypoint e implementas el método run, que recibe el evento que lo disparó y un objeto step. La magia está en el step: cuando un paso termina, su resultado se persiste de forma duradera. Si el proceso muere entre pasos, el motor lo reinicia y lo reproduce, pero en vez de volver a ejecutar los pasos ya completados, lee sus resultados guardados y salta directo a donde se quedó.

import { WorkflowEntrypoint, WorkflowStep, WorkflowEvent } from "cloudflare:workers";

type Params = { pedidoId: string };

export class ProcesarPedido extends WorkflowEntrypoint<Env, Params> {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const pago = await step.do("cobrar tarjeta", async () => {
      return await cobrar(event.payload.pedidoId);
    });

    await step.do("aprovisionar", async () => {
      await aprovisionar(pago.id);
    });

    await step.do("enviar confirmacion", async () => {
      await email(event.payload.pedidoId, pago.id);
    });
  }
}

El Workflow se declara con un binding en wrangler.jsonc y se dispara desde un Worker, que devuelve un identificador de instancia con el que consultar su estado más tarde:

// wrangler.jsonc -> "workflows": [{ "name": "procesar-pedido",
//   "binding": "PROCESAR_PEDIDO", "class_name": "ProcesarPedido" }]

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const instancia = await env.PROCESAR_PEDIDO.create({
      params: { pedidoId: "A-1001" },
    });
    return Response.json({ id: instancia.id });
  },
};

La consecuencia es que el estado de ejecución de tu propia función se vuelve duradero. No es que el código no falle nunca; es que su progreso sobrevive al fallo. Una instancia puede durar minutos, horas o semanas, y cada una tiene su identidad propia.

Código que recuerda dónde iba

flowchart LR
S1[step cobrar] --> P1[estado persistido]
P1 --> S2[step aprovisionar] --> P2[estado persistido]
P2 --> X[fallo o reinicio]
X -.reanuda.-> S3[step enviar confirmacion]
S3 --> DONE[completado]
style P1 fill:#a6e3a1,color:#11111b
style P2 fill:#a6e3a1,color:#11111b
style X fill:#f38ba8,color:#11111b

El salto mental es este: escribes código lineal y ordinario —sin máquina de estados explícita, sin anotar checkpoints a mano— y las fronteras entre pasos se convierten en checkpoints automáticos. Leyendo run de arriba abajo ves el proceso entero de un vistazo; pero en tiempo de ejecución esa misma función puede correr muchas veces, y en cada una avanza rápido sobre los pasos ya hechos reutilizando su resultado almacenado. Por eso el código parece simple y secuencial mientras es a prueba de caídas por debajo. Comparado con la versión artesanal, obtienes la misma fiabilidad con una décima parte del código, y la carga de la corrección se traslada de ti a la plataforma.