Cuánto puede durar una ejecución

Un workflow puede tardar segundos o puede tardar horas. Un envío de email termina enseguida; una sincronización nocturna que recorre miles de pedidos contra un ERP, no.

Floogos pone un tiempo máximo por ejecución para que un flujo mal construido no se quede corriendo para siempre. Esta página explica cómo funciona ese límite, qué ves cuando salta y cómo ajustarlo a tus procesos reales.

En una frase

Por defecto, una ejecución puede durar hasta 1 hora. Si necesitás más, se sube el límite o se quita. Y el límite nunca corta un nodo por la mitad.

---

Qué pasa cuando se agota el tiempo

La ejecución se marca como fallida y queda registrada con el motivo:

Tiempo máximo de ejecución superado (3612s)

A partir de ahí:

No se pierde el trabajo hecho

Los nodos que ya se completaron dejaron su resultado y su traza. Podés ver exactamente dónde se cortó.

Te avisa

Si tenés un Error Trigger configurado, se dispara igual que con cualquier otro fallo. No hay cortes silenciosos.

---

El corte no es instantáneo (y es a propósito)

Esta es la parte que más sorprende, así que conviene entenderla bien.

Floogos comprueba el tiempo entre un nodo y el siguiente, nunca en mitad de uno. Si el límite vence mientras un nodo está trabajando, el motor espera a que ese nodo termine y corta justo después.

1. El límite vence a los 60 minutos.

2. Pero hay una consulta SQL en curso que lleva 3 minutos ejecutándose.

3. El motor espera a que la consulta devuelva.

4. Corta ahí, y el error registra el tiempo real: 63 minutos.

Por eso es normal ver un tiempo algo mayor que el límite configurado. No es un fallo de precisión: es que cortar a un nodo por la mitad dejaría transacciones abiertas, ficheros a medio escribir o llamadas a APIs sin respuesta.

Consecuencia práctica

Si un solo nodo tarda mucho —una consulta pesada, una API lenta—, el corte se retrasa hasta que ese nodo acabe. Si necesitás cortar de verdad a un nodo lento, el límite hay que ponerlo en el propio nodo (por ejemplo, el timeout de la consulta SQL), no en la ejecución.

---

Cómo cambiar el límite

Subirlo

Si tenés procesos nocturnos largos y legítimos, poné un valor acorde. Un job que recorre un ERP entero puede necesitar varias horas.

Quitarlo

Se puede dejar sin límite de tiempo. No es peligroso: el freno real contra bucles es otro, y sigue activo (lo vemos abajo).

Solo en instalaciones on-premise

Las variables de entorno se configuran en el servidor donde corre Floogos, así que aplican a las instalaciones on-premise. En Floogos Cloud no tenés acceso a ellas: esos valores los gestiona el equipo de Floogos. Si necesitás cambiar alguno para tu cuenta, escribinos a soporte.

Se ajusta con estas dos variables de entorno:

Variable	Qué hace
WORKFLOW_MAX_EXECUTION_SEC	Fija el límite para todas las ejecuciones. 0 = sin límite.
WORKFLOW_DEFAULT_EXECUTION_SEC	El límite por defecto cuando no hay otro definido. Por defecto 3600 (1 hora).

0 significa sin límite

Tanto 0 como los valores negativos se interpretan como sin límite de tiempo. Si no querés ningún tope, WORKFLOW_MAX_EXECUTION_SEC=0 es la forma explícita de decirlo.

---

Por qué quitar el límite no es peligroso

La pregunta razonable es: si quito el tiempo máximo, ¿qué me protege de un bucle infinito?

El tope de nodos, que es una defensa distinta y sigue funcionando aunque no haya límite de tiempo.

Límite de tiempo

Mide cuánto dura la ejecución.

Un proceso legítimo puede durar horas → este límite estorba si es muy bajo.

Tope de nodos

Mide cuántos pasos ejecuta (10.000 por defecto).

Un proceso legítimo no ejecuta 10.000 nodos → este límite solo atrapa bucles.

Un bucle infinito ejecuta nodos sin parar, así que choca contra el tope de nodos en cuestión de segundos, mucho antes de agotar ningún tiempo. Un proceso lento pero correcto ejecuta pocos nodos durante mucho rato: el tope de nodos ni lo roza.

Por eso el tiempo es el freno menos importante de los dos, y por eso subirlo o quitarlo no reabre el riesgo de una ejecución desbocada.

Sub-workflows en bucle

Si el bucle está entre workflows (uno llama a otro que vuelve a llamar al primero), lo que actúa es la anti-recursión y el tope de profundidad, no el tiempo. Están descritos en la red de seguridad de ejecución.

---

Qué mirar cuando un flujo se corta

1. Revisá el mensaje del error. Distingue entre agotar el tiempo y superar el tope de nodos, y son problemas muy distintos.

2. Si es por tiempo: mirá si el proceso es legítimamente largo. Si lo es, subí el límite. Si no debería tardar tanto, el problema está en algún nodo lento — normalmente una consulta sin índice o una API que no responde.

3. Si es por tope de nodos: casi siempre es un bucle. Revisá que ningún nodo apunte hacia atrás en la cadena y que las iteraciones tengan una condición de salida.

4. Mirá dónde se cortó. La traza muestra el último nodo ejecutado: ese es el que hay que revisar primero.

---

Seguir leyendo

• Red de seguridad de ejecución — las seis defensas que impiden que un workflow desbocado afecte a la plataforma.
• Buenas prácticas de Sub Workflow — cómo encadenar workflows sin crear ciclos.
• Cola de reintentos — qué pasa con una ejecución que falla.