Hola @ricardo_balako
El error que estás experimentando, “Cannot read properties of undefined (reading ‘execute’)”, es un síntoma clásico de un fallo de comunicación en el modo de cola de n8n. Dado que tu flujo de trabajo funciona correctamente dentro del editor pero falla en producción, el problema casi con certeza no está en la lógica de tu flujo de trabajo en sí, sino en cómo tu entorno distribuido está manejando el trabajo. En modo de cola, la instancia principal envía una tarea a un proceso worker separado, y si ese worker no puede inicializar correctamente el nodo requerido, se bloquea antes de poder comenzar siquiera la ejecución.
La causa más común de esto es una falta de coincidencia de versiones entre tu instancia principal y tu instancia worker. Incluso si ambas parecen estar ejecutando la última versión, las diferencias sutiles en las imágenes de Docker subyacentes pueden impedir que se comuniquen correctamente. Es esencial asegurar que ambos servicios estén utilizando explícitamente la misma etiqueta de imagen exacta y que realices un redesplegue completo de ambos componentes simultáneamente para garantizar que estén sincronizados.
Otro factor crítico es la consistencia de tus variables de entorno en toda tu infraestructura. Tus servicios principal y worker deben compartir la misma configuración exacta, particularmente respecto a la clave de cifrado, los detalles de conexión de la base de datos y la configuración de Redis. Si el worker carece de la configuración correcta, puede fallar al autenticarse con tu base de datos o Redis, provocando el error “undefined” cuando intenta recuperar los datos del flujo de trabajo que necesita para iniciar el trabajo.
También deberías verificar que tu servicio worker esté configurado para ejecutarse específicamente como un proceso worker. En tu configuración de Easypanel, confirma que el comando para tu contenedor worker esté establecido en worker (por ejemplo, n8n worker). Además, establecer la variable de entorno N8N_REINSTALL_MISSING_PACKAGES=true en tu worker es una buena práctica, ya que asegura que el worker tenga todas las dependencias necesarias, como las requeridas por el nodo AI Agent, que podrían faltar en un entorno worker nuevo.
El hecho de que el error apunte a bull (la biblioteca de gestión de colas) confirma que el fallo está ocurriendo a nivel de infraestructura. La mejor manera de llegar al fondo de esto es ignorar los registros principales de n8n y enfocarse exclusivamente en los registros del contenedor worker en el momento exacto en que envíes el formulario. Estos registros específicos del worker a menudo proporcionarán la razón específica—como un tiempo de espera de conexión o una dependencia faltante—por la que el trabajo no se pudo inicializar.
Si has verificado el versionado, la configuración y los registros y el problema persiste, es posible que quieras hacer una prueba estableciendo EXECUTIONS_PROCESS=main en tu instancia principal como un paso diagnóstico temporal. Aunque esto evita la infraestructura de worker, confirmará si el problema está estrictamente relacionado con el sistema de colas. Si el flujo de trabajo se ejecuta bien en este modo, confirma que tu problema está aislado a la interacción entre tu instancia principal de n8n y los procesos worker.