Ejecuciones en las que puedes confiar

Nadie se fija en una automatización hasta que envía algo dos veces

Entonces todo el mundo se fija. Los cuatro mecanismos de esta página existen porque los fallos de este tipo de software son siempre los mismos cuatro fallos, y todos se evitan por diseño en lugar de por cuidado.

Simula antes de publicar

Empuja un registro real a través de un flujo de trabajo desactivado, y lee exactamente lo que habría ocurrido: el camino tomado, cada valor en cada paso, la redacción de cada mensaje y la solicitud que habría ido a cada sistema externo.

Nada sale del edificio. No se envía ningún correo, no se emite ninguna factura, no se intenta ningún cobro, no se escribe ninguna fila. Las llamadas externas se registran como intenciones, con la carga que se habría enviado, para que puedas ver si el mapeo es correcto antes de que se convierta en problema de alguien.

Las simulaciones son la forma de responder a la pregunta que impide a la gente activar una automatización: ¿qué hará esto realmente?

Simulación · pedido 88 214Nada enviado

1Validar direcciónCoincidió. Habría escrito 6 campos.
?Condición¿Pedido de más de 1 000 zł? No — 289,00 zł. Se tomó la ruta corta.
3FacturaHaría un POST al sistema de facturación. El payload se muestra completo.
!Detectado aquíEl tipo de IVA se mapeó desde el campo equivocado. Detectado en una simulación y no en la bandeja de entrada de un contable.

Enviado: nadaCobrado: nada

Una ejecución recorre la versión en la que entró

Publicar un cambio en un flujo de trabajo no afecta a las ejecuciones que ya están dentro de él. Cada ejecución queda fijada a la versión en la que empezó y termina esa versión, por mucho que tarde y por mucho que reescribas mientras tanto.

Así puedes reestructurar un flujo de trabajo mientras diez mil personas están a mitad de camino, y cada una de ellas completa el flujo que se le prometió. La alternativa —el diseño donde toda la ruta posterior se materializa al entrar— es la razón por la que editar una automatización en vivo parece peligroso en la mayoría de las herramientas. Aquí no tiene nada de especial.

Las ejecuciones nuevas obtienen la nueva versión desde el momento en que publicas. La versión en la que está una ejecución queda registrada en la propia ejecución, así que una pregunta sobre el comportamiento en marzo tiene respuesta en septiembre.

Editar en vivov4 → v5

1Antes2 918 ejecuciones en curso, todas en v4. Algunas en una espera de dos días.
2Publicar v511:40Dos pasos reordenados, un mensaje reescrito.
3DespuésEsas 2 918 terminan en v4. Todo lo que empiece a partir de las 11:40 ejecuta v5.
§Nadierecibió la mitad de un flujo de trabajo y la mitad de otro.

Versión registrada en cada ejecuciónVersiones antiguas conservadas

Reintentos que no pueden enviar dos veces

Un paso es una función pura de sus entradas, y sus efectos se confirman junto con el propio avance de la ejecución al siguiente paso. No hay ninguna ventana en la que el mensaje haya salido pero la ejecución no lo sepa.

Ese es todo el truco, y es una propiedad estructural y no una promesa. Un trabajador eliminado a mitad de un paso —un despliegue, un fallo, una máquina que desaparece— deja la ejecución exactamente donde estaba. Otro trabajador la recoge y vuelve a ejecutar el paso. Como el efecto y el avance se confirman como uno solo, o ocurrieron ambos o no ocurrió ninguno.

Las llamadas salientes a sistemas que admiten claves de idempotencia llevan una, derivada de la ejecución y del paso, para que el otro lado también pueda reconocer la repetición.

Trabajador eliminado a mitad del envíoRecuperado

1Comienza el paso 509:14:06Enviar el aviso de envío.
✕El trabajador muere09:14:07Despliegue. No se había confirmado nada.
2Recogida09:14:31Otro trabajador encuentra la ejecución todavía en el paso 5.
✓Enviado una vez09:14:32El cliente recibió un correo electrónico, no dos.

Los efectos se confirman junto con el avanceClave de idempotencia por ejecución y paso

Un registro escrito para que lo lea una persona

Cada ejecución, cada paso, la rama que tomó y el valor que lo decidió. Tiempos por paso. La petición y la respuesta de cada llamada externa, con credenciales ocultas. La versión en la que estaba la ejecución. Dónde está esperando una ejecución y hasta cuándo.

Cuando alguien pregunta qué pasó con el pedido hecho el catorce, hay una respuesta, y encontrarla lleva un minuto en lugar de una tarde correlacionando los registros de tres sistemas.

Las ejecuciones que fallan se reúnen en un solo lugar con la causa agrupada, así «cuarenta y un fallos durante la noche» se resuelve en «un proveedor devolvió 503 durante nueve minutos» en lugar de cuarenta y una investigaciones separadas.

Durante la noche, agrupados41 fallos

1Una causaLa API del proveedor devolvió 503 entre las 02:41 y las 02:50.
2Qué pasóLos 41 se reintentaron; 39 tuvieron éxito en el segundo intento.
3PendientesDos se detuvieron y están esperando a una persona. Ambos figuran en la lista con la fila que falló.
§No cuarenta y unainvestigaciones. Una, y una decisión sobre dos registros.

Credenciales ocultasVersión registrada

Lo que no afirmamos

No publicamos una cifra de disponibilidad en una página de marketing, porque un número sin una ventana de medición y una definición de «disponible» es decoración. Si la necesitas contractualmente, pregúntanos y hablaremos de a qué podemos comprometernos de verdad.

Tampoco podemos hacer fiable la API de otra persona. Si un proveedor está caído, un flujo de trabajo que dependa de él espera, reintenta y finalmente se detiene con un motivo claro. Lo que podemos prometer es que el fallo es visible, que no corrompe nada y que reanudar no envía el mensaje una segunda vez.

Sobre las esperas: una ejecución que espera dos días es un wake_at en la ejecución, no un trabajo sentado en una cola. Por eso un flujo de trabajo puede mantener cien mil ejecuciones en una espera de tres semanas sin que nada de eso cueste nada, y por eso el número de ejecuciones esperando actualmente no es algo en lo que tengas que pensar.