Nodo delay

core.delay detiene el job hasta un momento futuro y lo reanuda solo. Sirve para recordatorios, seguimientos de SLA, secuencias de cobranza, vencimientos de prueba: cualquier proceso donde el paso siguiente es "esperar".

Configuración#

Dos formas, excluyentes.

Relativa#

{ "delay": "5d" }

Unidades: s (segundos), m (minutos), h (horas), d (días). El tope es 365 días.

Absoluta, desde los datos#

{ "until": "body.dueDate" }

Una expresión JSONata que tiene que resolver a una fecha ISO-8601. Útil cuando la fecha viene en el payload: "reanudá el día antes del vencimiento de la factura".

Qué le pasa al job#

Mientras espera, el job queda en estado WaitingTimer. No ocupa un worker — no hay un hilo dormido en ninguna parte. La espera vive como una fila en la base de datos y un barredor la levanta cuando vence.

Cuando reanuda, el grafo se vuelve a correr desde el principio, pero los nodos que ya se completaron devuelven su resultado guardado en vez de ejecutarse otra vez. El propio nodo delay se cortocircuita al ver que su espera ya venció.

Precisión#

El barredor corre una vez por minuto. Un delay de 5 días reanuda dentro del minuto correcto, no del segundo.

Para esperas de días eso no se nota. Si necesitás precisión por debajo del minuto, este nodo no es la herramienta.

Versión congelada#

Un job parqueado sigue con la versión del flujo con la que arrancó. Si publicás una versión nueva durante la espera, ese job no la toma.

Es a propósito: el nodo en el que está parado tiene que seguir existiendo en el grafo que se reanuda. Al publicar, Orquesto te dice cuántos jobs quedaron en versiones viejas para que decidas si cancelarlos.

Cancelar una espera#

Un job en WaitingTimer se puede cancelar desde la pantalla del job. Pasa a Cancelled y el temporizador queda sin efecto.

Límites#