Error Trigger

Descripción

El Error Trigger es un trigger especial que activa un workflow cuando uno o varios workflows sufren un error fatal durante la ejecución. Funciona como mecanismo global de gestion de errores, similar al Error Trigger de n8n.

Coloca este nodo en un workflow dedicado al manejo de errores. Cuando cualquier workflow monitoreado falla, Floogos invoca automáticamente ese workflow handler con el contexto completo del fallo: mensaje de error, stack trace, el nodo que fallo y el último payload de datos en circulación antes del crash.

Como funciona

Un workflow se ejecuta y falla (un nodo lanza una excepción o se cuelga)
El motor de Floogos detecta el fallo y busca todos los workflows Error Trigger activos registrados para ese cliente
Filtra por watched_workflow_ids — si esta vacío, el handler se dispara para cualquier workflow que falle
El workflow handler se invoca de forma asincrona con el contexto del error como datos de entrada
Tu lógica de manejo de errores se ejecuta: enviar alerta, registrar en base de datos, reintentar via Sub-Workflow, etc.

Configuración

Parámetro	Tipo	Requerido	Descripción
watched_workflow_ids	workflow_multi_selector	No	Workflows a vigilar. Deja vacío para capturar errores de todos los workflows del cliente.

Un único workflow handler puede vigilar varios workflows especificos, o actuar como catch-all dejando el campo vacío.

Datos de salida

Cuando se dispara, el nodo pasa el siguiente payload al siguiente nodo:

{
  "error_message": "Cannot read properties of undefined (reading 'price')",
  "error_type": "module_error",
  "error_stack": "TypeError: Cannot read...\n    at Object.<anonymous> (/modules/http/index.js:42:18)",

  "failed_workflow_id": 87,
  "failed_workflow_name": "Procesar Pedidos",
  "failed_node": "HTTP_Request",
  "workflow_instance_id": "exec_1714823901234",

  "is_production": true,
  "is_dev": false,
  "timestamp": "2026-04-22T10:34:01.234Z",

  "last_data": {
    "order_id": "ORD-4821",
    "customer_email": "usuario@ejemplo.com",
    "total": 129.99
  },

  "execution_logs": [
    { "node": "Webhook", "status": "ok", "duration_ms": 3 },
    { "node": "HTTP_Request", "status": "error", "error": "Cannot read..." }
  ]
}

Referencia de campos

Campo	Tipo	Descripción
error_message	string	Mensaje de error legible
error_type	string	`module_error` (excepción en nodo) o `code_error` (error en script)
error_stack	string	Stack trace completo (null si no disponible)
failed_workflow_id	number	ID del workflow que fallo
failed_workflow_name	string	Nombre visible del workflow fallido
failed_node	string	Etiqueta del nodo que causo el error
workflow_instance_id	string	ID único de ejecución para correlación con trazas
is_production	boolean	Si el workflow corria en modo producción
is_dev	boolean	Si era una ejecución de prueba/dev
timestamp	string	Timestamp ISO 8601 del fallo
last_data	object	Payload de datos en el momento del fallo
execution_logs	array	Resumen de ejecución por nodo hasta el punto del fallo

Ejemplos de uso

Ejemplo 1 — Alerta en Slack cuando falla cualquier workflow

Un handler catch-all que envia un mensaje de Slack cada vez que cualquier workflow falla.

Configuración del Error Trigger:

{
  "label": "Error Trigger",
  "watched_workflow_ids": []
}

Nodo Slack (usando variables dinámicas):

❌ Workflow fallido: {{@ErrorTrigger.failed_workflow_name}}
Nodo: {{@ErrorTrigger.failed_node}}
Error: {{@ErrorTrigger.error_message}}
Hora: {{@ErrorTrigger.timestamp}}

Flujo completo:

ErrorTrigger (todos los workflows)
  → Slack (publicar en canal #alertas)
  → End

Ejemplo 2 — Correo con el último payload

Captura fallos en un workflow critico especifico y envia un email al equipo con el contexto completo.

Configuración del Error Trigger:

{
  "label": "Error Trigger",
  "watched_workflow_ids": [42]
}

Nodo SendMail:

Para: ops@empresa.com
Asunto: [ERROR] {{@ErrorTrigger.failed_workflow_name}} ha fallado
Cuerpo:
  Nodo que fallo: {{@ErrorTrigger.failed_node}}
  Error: {{@ErrorTrigger.error_message}}
  Ultimo payload: {{@ErrorTrigger.last_data}}
  Instancia: {{@ErrorTrigger.workflow_instance_id}}

Flujo completo:

ErrorTrigger (workflow ID 42)
  → SendMail (notificar al equipo ops)
  → End

Ejemplo 3 — Registrar en DataStore y reintentar via Sub-Workflow

Almacena cada error en una tabla DataStore e intenta volver a ejecutar el workflow fallido.

ErrorTrigger (todos los workflows)
  → DataStore (insertar en tabla error_log)
  → Decision (is_production == true?)
      → true: Sub-Workflow (re-disparar workflow fallido con last_data)
      → false: End

Configuración del nodo DataStore:

{
  "action": "insert",
  "table": "error_log",
  "data": {
    "workflow_id": "{{@ErrorTrigger.failed_workflow_id}}",
    "workflow_name": "{{@ErrorTrigger.failed_workflow_name}}",
    "failed_node": "{{@ErrorTrigger.failed_node}}",
    "error_message": "{{@ErrorTrigger.error_message}}",
    "timestamp": "{{@ErrorTrigger.timestamp}}"
  }
}

Ejemplo 4 — Vigilar varios workflows con alerta por Telegram

Vigila dos workflows de procesamiento de pedidos y envia un aviso por Telegram al ingeniero de guardia.

Configuración del Error Trigger:

{
  "label": "Error Trigger",
  "watched_workflow_ids": [12, 35]
}

ErrorTrigger (workflows 12 y 35)
  → Telegram (enviar a @bot_guardia)
  → End

Mensaje de Telegram:

🚨 *Error en {{@ErrorTrigger.failed_workflow_name}}*
Nodo: `{{@ErrorTrigger.failed_node}}`
Mensaje: {{@ErrorTrigger.error_message}}
Pedido en vuelo: {{@ErrorTrigger.last_data.order_id}}

Ejemplo 5 — Pipeline completo de gestión de errores

Flujo de respuesta ante errores en producción con alerta, registro y reintento condicional.

ErrorTrigger (todos los workflows)
  → SetVariable (guardar contexto del error)
  → DataStore (insertar en error_log)
  → Decision (error_type == "module_error" Y is_production == true?)
      → true:
          → SendMail (alertar al equipo tecnico)
          → Slack (notificar a #incidencias)
          → Decision (last_data tiene order_id?)
              → true: Sub-Workflow (reintentar procesamiento del pedido)
              → false: End
      → false: End

Buenas practicas

Un catch-all + handlers especificos: crea un handler genérico (sin watched_workflow_ids) para alertas, y handlers separados para workflows que necesiten lógica de reintento o procesamiento especial.
Usa last_data para contexto: el payload en el momento del fallo suele contener suficiente información (ID de pedido, email del cliente, etc.) para tomar medidas correctivas sin volver a consultar sistemas externos.
Usa workflow_instance_id para correlación: enlaza los registros de error con la traza completa en la vista Trazas de Floogos para depurar la causa raiz.
Evita bucles infinitos: no vigiles el propio workflow handler. Floogos previene bucles directos, pero es buena práctica mantener los handlers simples y robustos.
Prueba en modo dev: usa el tester de workflows para simular un error y verificar que el handler se dispara correctamente antes de ir a producción.

Notas

El Error Trigger se dispara de forma asincrona — no afecta al tiempo de respuesta del caller del workflow fallido.
Si varios workflows Error Trigger vigilan el mismo workflow origen, todos se disparan simultaneamente.
El workflow handler se ejecuta como un workflow de producción (sin flag dev especial a menos que el fallo original fuera en modo dev).
Solo los errores fatales (excepciones no controladas) disparan este nodo. Los errores manejados (capturados dentro de nodos Script, por ejemplo) no activan el Error Trigger.

Nodos relacionados

Webhook — trigger HTTP genérico
Sub-Workflow — llamar a otro workflow para reintentar la operación fallida
DataStore — persistir registros de errores
SendMail — alertas por correo
Slack — alertas en Slack