Estoy enfrentando un problema donde un flujo de trabajo con un nodo Email Trigger (IMAP) se desactiva inmediatamente cuando intento activarlo, lanzando un WorkflowActivationError que es capturado por el Error Trigger del flujo de trabajo.
Sin embargo, la ejecución manual funciona perfectamente sin ningún error.
Detalles del error (capturado por Error Trigger):
[
{
"trigger": {
"error": {
"message": "There was a problem with the trigger node \"Email Trigger (IMAP)\", for that reason did the workflow had to be deactivated",
"timestamp": 1785767782822,
"name": "WorkflowActivationError",
"context": {}
},
"mode": "trigger"
},
"workflow": {
"id": "zTAdqKiYBPODh3yr",
"name": "03.03. Яндекс -> amoCRM (deleted@pioneercert.ru)"
}
}
]
Hola @Sokol
WorkflowActivationError es el contenedor que n8n entrega al Error Trigger cuando falla un nodo disparador, y los errores de nodo disparador siempre llegan con context: {} y sin causa, por lo que la falla real de IMAP nunca llega a la interfaz de usuario y va al registro de instancias en su lugar. Las ejecuciones manuales realizan una única búsqueda y cierre, la activación mantiene la conexión abierta, por lo que solo la activación genera el error. Activa el flujo de trabajo y lee el registro inmediatamente después:
La línea que comienza “Email Read Imap:” contiene la razón real, generalmente una conexión cerrada inesperadamente, un rechazo de autenticación del servidor o un error de buzón, y eso determina la solución. En Cloud esos registros no son accesibles desde tu lado, help@n8n.io puede extraerlos del flujo de trabajo zTAdqKiYBPODh3yr.
El detalle faltante en la carga del error se registra aquí:
Hemos revisado esto y parece que podría estar solucionado en una versión reciente. Por favor, actualiza y comprueba si sigues experimentando el mismo problema.
Hola,
Sigo en 2.33.3, el mismo patrón ECONNRESET/EPIPE que antes de la actualización, sin cambios.
Una cosa que noté es que no está aislado a un solo buzón, mail@, deleted@ y notification@ en el mismo VPS se están caída al mismo tiempo, en el mismo bucle cerrado del sistema. Eso me hizo preguntarme si esto es realmente algo de la capa de red, y no algo que Yandex o n8n esté haciendo por cuenta. Como el firewall del VPS o la tabla conntrack eliminando conexiones inactivas antes de que n8n tenga la oportunidad de reconectarse.
No he verificado el tiempo de espera de conntrack aún, ejecutaré
sysctl net.netfilter.nf-conntrack-tcp-timeout-established y publicaré el valor. También voy a ver cuál es la configuración actual de Force Reconnect en estos nodos, ya que no estoy seguro de que esté siquiera configurado.
¿Por qué la configuración de 15 minutos no coincide con lo que vi en el registro?
Aprecio que lo compartas. Un elemento destaca: aunque Force Reconnect está configurado para 15 minutos, los problemas de ECONNRESET/EPIPE se producían en cascada en un bucle cerrado en lugar de aproximadamente cada 15 minutos, según el registro que compartiste anteriormente. Esperarías fallos dispersos aproximadamente cada 15 minutos en lugar de un pico repentino si Force Reconnect fuera el culpable. Por lo tanto, esta opción probablemente no sea la razón principal; la conexión se está terminando mucho antes de que pasen los 15 minutos asignados.
Vale la pena verificar si los valores de los otros buzones (mail@, notification@) son iguales o si uno está configurado diferente o sin establecer. Eso facilitaría determinar si se trata de una configuración por nodo o algo que los afecta a todos por igual.
Aún planeando verificar el tiempo de espera de conntrack, publicaré ese valor una vez que lo tenga — ese es el dato que realmente nos dirá si es el VPS/firewall o algo en el manejo de reconexión de n8n.
Si necesitas datos adicionales o si envié algo incorrecto, por favor házmelo saber. Enviaré la información adicional para que podamos encontrar una solución.
ejecuta docker logs n8n-n8n-worker-1 2>&1 | grep -i imap y ve qué resultado obtienes. Proporcióname los resultados.
También qué está configurado en EXECUTIONS_MODE (o si estás usando N8N_DISABLE_PRODUCTION_MAIN_PROCESS).
También proporciona la salida del registro del worker de alrededor del mismo período de tiempo que uno de los fallos en tu captura de pantalla de docker ps/log, así los timestamps pueden alinearse con los fallos del proceso principal.
si ese error de LOGIN aparece repetidamente en diferentes buzones, y si las marcas de tiempo se agrupan cercanamente, porque si múltiples buzones en el mismo dominio/IP están reintentando LOGIN alrededor de los mismos momentos, eso parece que el anti-abuso/limitación de velocidad de Yandex se está activando por intentos de login repetidos golpeando desde una IP de VPS, no un problema por cuenta.
Mi sugerencia:
ese código sc= es un identificador de rastreo/soporte del lado de Yandex, vale la pena que lo lleves directamente al soporte de Yandex, ya que si esto es limitación de velocidad, no es algo que sea reparable puramente desde el lado de la configuración de n8n.
@Sokol la llamada que falla es LOGIN, no el socket. “LOGIN internal server error sc=…_imap-production-main-623” es Yandex rechazando la sesión, y los pares ECONNRESET y EPIPE son esas sesiones siendo cerradas inmediatamente después. Ningún cambio de configuración de n8n cambia eso, la solución está en el lado del buzón.
Para cada uno de deleted@, mail@ y notification@:
Inicia sesión en ese buzón una vez en mail.yandex.com. El Acuerdo de Usuario se acepta en el primer inicio de sesión web, por buzón, y los buzones de servicio generalmente nunca lo han sido.
En Configuración > Clientes de correo electrónico, confirma que “Desde el servidor imap.yandex.com a través de IMAP” está activado y el método de autorización está configurado en contraseñas de aplicación.
Genera una contraseña de aplicación para ese buzón en Yandex ID y úsala en la credencial IMAP de n8n en lugar de la contraseña de la cuenta.
Yandex también bloquea buzones que su sistema de seguridad marca como sospechosos, generalmente los que no tienen nombre real o teléfono vinculado, y ese bloqueo se levanta por sí solo después de un par de horas, lo que se ajusta a los errores que van y vienen mientras las ejecuciones manuales aún funcionan. Troubleshooting email client issues | Yandex Mail
