Estoy ejecutando n8n en Queue Mode (Redis + Worker + Database) y encontré un problema donde no puedo determinar de forma confiable el último nodo ejecutado cuando Redis no está disponible.
Describe el problema/error/pregunta
Durante la ejecución del flujo de trabajo, si Redis se desconecta o se reinicia, ocurre el siguiente comportamiento:
La ejecución permanece en estado de ejecución en la base de datos
Ningún progreso de ejecución es visible en la interfaz de usuario
Después de que Redis se recupera, la ejecución no se reanuda ni actualiza el progreso
Después de reiniciar la instancia principal de n8n, el estado de ejecución se actualiza a bloqueado
Sin embargo, la interfaz de usuario y los datos de ejecución no muestran claramente en qué nodo se detuvo el flujo de trabajo
Información sobre tu configuración de n8n
- versión de n8n: 2.11.4
- Base de datos (predeterminada: SQLite): pgsql
- configuración de n8n EXECUTIONS_PROCESS (predeterminada: own, main):
- Ejecutando n8n mediante (Docker, npm, n8n cloud, aplicación de escritorio): Docker
- Sistema operativo:
Pregunta
- ¿Hay alguna forma oficial o recomendada para determinar el último nodo completado exitosamente en este escenario?
Hola @halouprogramer
Tu configuración de n8n utiliza Redis como un “mensajero” para coordinar el trabajo entre el sistema principal y los workers. Cuando Redis se desconecta, el mensajero desaparece, lo que significa que el sistema principal nunca recibe la señal de que una tarea ha finalizado. Esto deja la tarea atrapada en estado “en ejecución”. Cuando reinicías el sistema, n8n nota que la tarea nunca terminó oficialmente y la marca como “fallida” como una forma de limpiar.
Alunque la tarea está etiquetada como “fallida”, n8n generalmente guarda los resultados de cada paso individual (nodo) en tu base de datos sobre la marcha. El problema es que la interfaz de usuario de n8n no está diseñada para mostrar este progreso parcial para las ejecuciones fallidas. Por eso la interfaz se ve en blanco o no resalta dónde se detuvo el flujo de trabajo, aunque los datos realmente existen.
Para saber exactamente cuál fue el último nodo en terminar, necesitas omitir la interfaz de usuario y mirar directamente tu base de datos PostgreSQL. Al buscar el ID de ejecución específico en las tablas de la base de datos, puedes ver los datos brutos de esa ejecución. El último nodo que guardó exitosamente su resultado en la base de datos es donde se detuvo el flujo de trabajo.
SELECT data
FROM execution_entity
WHERE id = YOUR_EXECUTION_ID;
Nota: Ejecuta la siguiente consulta en tu instancia de Postgres (reemplaza YOUR_EXECUTION_ID con el ID real)
Para evitar que esto vuelva a suceder en el futuro, puedes ajustar algunos parámetros para hacer tu sistema más resiliente. Aumentar el tiempo de espera de Redis le da a n8n más tiempo para recuperarse de breves interrupciones de red, y establecer un “Execution Timeout” máximo asegura que las tareas atrapadas se cierren automáticamente en lugar de quedarse en estado “en ejecución” indefinidamente.
¡Bienvenido a la comunidad @halouprogramer!
En el modo de cola, lamentablemente lo que ves es lo esperado: una vez que Redis se cae durante la ejecución, la instancia principal nunca recibe una señal clara de “he terminado” del worker, por lo que la ejecución permanece en “en ejecución” hasta que algo la limpia, y cuando se limpia, se marca como “crasheada” sin contexto a nivel de nodo en la interfaz.
Si realmente necesitas saber “¿dónde se detuvo esto?”, básicamente tienes dos opciones:
-
De ahora en adelante: activa “Guardar Progreso de Ejecución” (Save Execution Progress) para este flujo de trabajo, para que n8n escriba datos después de cada nodo y puedas ver el último nodo completado incluso cuando el estado final sea crasheado.
-
Ahora mismo / retroactivamente: consulta tu tabla execution_entity de Postgres para el ID de ejecución específico e inspecciona el payload data directamente – ese JSON sin procesar generalmente contiene el último nodo que logró persistir su salida, aunque la interfaz no lo muestre para ejecuciones crasheadas.
Más allá de eso, el único arreglo real es mantener Redis estable (timeouts, reconexión, lado de infraestructura), porque mientras el “mensajero” pueda desaparecer aleatoriamente, n8n no tiene una forma confiable de cerrar el ciclo y marcar la ejecución con un estado final preciso.
Yo lo trataría como un problema de observabilidad y diseño de recuperación, no solo como un problema de Redis. Para flujos de trabajo en producción, agrega registro de puntos de control alrededor de nodos críticos para que puedas saber qué se completó incluso si la interfaz de ejecución solo muestra que falló. Luego revisa el comportamiento de reinicio de la cola/trabajador y la persistencia de Redis, porque sin puntos de control el flujo de trabajo puede fallar de la peor manera posible: a medio completar sin un punto de reanudación obvio.