Je suis confronté à un problème où un workflow avec un nœud Email Trigger (IMAP) se désactive immédiatement lorsque j’essaie de l’activer, lançant une WorkflowActivationError qui est capturée par le Error Trigger du workflow.
Cependant, l’exécution manuelle fonctionne parfaitement sans aucune erreur.
Détails de l’erreur (capturée par 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)"
}
}
]
Salut @Sokol
WorkflowActivationError est le wrapper que n8n transmet au Error Trigger quand un nœud de déclenchement échoue, et les erreurs de nœud de déclenchement arrivent toujours avec context: {} et sans cause, donc l’échec IMAP réel n’atteint jamais l’interface utilisateur et va dans le journal des instances à la place. Les exécutions manuelles font un seul fetch et ferment, l’activation maintient la connexion ouverte, c’est pourquoi seule l’activation le déclenche. Activez le workflow et lisez le journal immédiatement après :
La ligne commençant par « Email Read Imap: » porte la vraie raison, généralement une connexion fermée de manière inattendue, un rejet d’authentification du serveur, ou une erreur de boîte aux lettres, et cela décide du correctif. Sur Cloud, ces journaux ne sont pas accessibles de votre côté, help@n8n.io peut les récupérer pour le workflow zTAdqKiYBPODh3yr.
Le détail manquant dans la charge utile d’erreur est suivi ici :
Nous avons examiné cela et il semble que cela pourrait être corrigé dans une version récente. Veuillez mettre à jour et vérifiez si vous rencontrez toujours le même problème.
Bonjour,
Toujours sur 2.33.3, même schéma ECONNRESET/EPIPE qu’avant la mise à jour, aucun changement.
J’ai remarqué une chose, ce n’est pas isolé à une seule boîte aux lettres, mail@, deleted@ et notification@ sur le même VPS sont tous déconnectés en même temps, dans le même système de boucle serrée. Cela m’a fait me demander si c’est vraiment une question de couche réseau, et non quelque chose que Yandex ou n8n fait par compte. Comme le pare-feu VPS ou la table conntrack qui supprime les connexions inactives avant que n8n ait la chance de se reconnecter.
Je n’ai pas encore vérifié le délai d’expiration conntrack, je vais exécuter
sysctl net.netfilter.nf-conntrack-tcp-timeout-established et poster la valeur. Je vais aussi vérifier sur quel paramètre Force Reconnect est actuellement configuré sur ces nœuds car je ne suis pas sûr que ce soit même configuré.
Pourquoi le paramètre de 15 minutes ne correspond-il pas à ce que j’ai vu dans le journal ?
J’apprécie que vous le partagiez. Un élément se démarque : bien que Force Reconnect soit défini sur 15 minutes, les problèmes ECONNRESET/EPIPE se produisaient dos à dos dans une boucle serrée plutôt que grossièrement toutes les 15 minutes, selon le journal que vous avez fourni précédemment. Vous vous attendriez à des défaillances espacées d’environ 15 minutes les unes des autres plutôt qu’à un pic soudain si Force Reconnect était le facteur. Par conséquent, cette option n’est très probablement pas la raison principale ; la connexion est terminée bien avant les 15 minutes allouées.
Il vaut la peine de vérifier si les valeurs des autres boîtes aux lettres (mail@, notification@) sont les mêmes ou si l’une est définie différemment ou non définie. Cela rendrait plus facile de déterminer s’il s’agit d’une configuration par nœud ou de quelque chose qui les affecte tous de manière égale.
Toujours prévu de vérifier le délai d’expiration conntrack, je publierai cette valeur une fois que je l’aurai — c’est la partie qui nous dira réellement si c’est le VPS/pare-feu ou quelque chose dans la gestion de reconnexion de n8n.
Si tu as besoin de données supplémentaires ou si j’ai envoyé quelque chose de mal, fais-le-moi savoir. Je t’enverrai les informations complémentaires pour qu’on puisse trouver une solution.
exécutez docker logs n8n-n8n-worker-1 2>&1 | grep -i imap et voyez ce qui revient. Fournissez-moi les résultats.
Aussi, à quoi EXECUTIONS_MODE est défini (ou si vous utilisez N8N_DISABLE_PRODUCTION_MAIN_PROCESS).
Fournissez également la sortie du journal du worker à partir de la même fenêtre temporelle que l’une de vos défaillances dans votre capture d’écran docker ps/log, afin que les horodatages puissent réellement être alignés sur les défaillances du processus principal.
que cette erreur LOGIN apparaisse à plusieurs reprises sur les différentes boîtes aux lettres, et que les horodatages se regroupent près les uns des autres, car si plusieurs boîtes aux lettres sur le même domaine/IP réessaient tous LOGIN autour des mêmes moments, cela ressemble à la limitation du taux/anti-abus de Yandex qui s’active suite à des tentatives de connexion répétées provenant d’une même adresse IP VPS, et non à un problème par compte.
Ma suggestion :
ce code sc= est un identifiant de trace/support du côté de Yandex, cela vaut la peine de le transmettre directement au support de Yandex, car si c’est une limitation de débit, ce n’est pas quelque chose qui peut être corrigé uniquement à partir de la configuration n8n.
@Sokol l’appel qui échoue est LOGIN, pas la socket. « LOGIN internal server error sc=…_imap-production-main-623 » est Yandex qui refuse la session, et les paires ECONNRESET et EPIPE sont ces sessions qui sont interrompues juste après. Aucun changement de paramètre n8n ne change cela, la correction se fait du côté de la boîte aux lettres.
Pour chacune des boîtes deleted@, mail@ et notification@ :
Connectez-vous à cette boîte aux lettres une fois sur mail.yandex.com. Les Conditions d’utilisation sont acceptées à la première connexion Web, par boîte aux lettres, et les boîtes aux lettres de service n’y ont généralement jamais accédé.
Dans Paramètres > Clients de messagerie, confirmez que « Depuis le serveur imap.yandex.com via IMAP » est activé et que la méthode d’autorisation est définie sur les mots de passe d’application.
Générez un mot de passe d’application pour cette boîte aux lettres dans Yandex ID et utilisez-le dans les identifiants IMAP n8n au lieu du mot de passe du compte.
Yandex bloque également les boîtes aux lettres que son système de sécurité signale comme suspectes, généralement celles sans nom réel ou numéro de téléphone lié, et ce blocage disparaît de lui-même après quelques heures, ce qui correspond aux erreurs qui apparaissent et disparaissent tandis que les exécutions manuelles fonctionnent toujours. Troubleshooting email client issues | Yandex Mail
