Je crée un flux de travail qui reçoit des e-mails entrants (avec une pièce jointe) en utilisant le nœud Email Trigger (IMAP).
Quand j’ouvre le flux de travail dans l’éditeur, je clique sur Execute Workflow et j’envoie un e-mail de test, le déclencheur se déclenche correctement et je reçois la pièce jointe réelle — tout fonctionne comme prévu.
Cependant, après avoir publié le flux de travail pour qu’il s’exécute en production, les nouveaux e-mails entrants ne déclenchent pas du tout le flux de travail. Aucune exécution n’est créée et rien n’apparaît dans la liste des exécutions.
Je suis sur n8n 2.0.3. Les choses que j’ai déjà exclues :
- La version publiée est la même que celle qui fonctionne lors de l’exécution manuelle (vérifiée dans l’historique des versions).
- J’envoie un nouvel e-mail non lu après la publication — pas un e-mail précédemment ouvert/lu.
- Les identifiants IMAP sont valides (l’exécution manuelle fonctionne à chaque fois).
Merci d’avance pour votre aide !
Veuillez partager votre flux de travail
Partagez la sortie renvoyée par le dernier nœud
Aucune sortie — le nœud de déclenchement ne se déclenche jamais quand le flux de travail est publié, donc il n’y a pas d’exécution à inspecter. En mode manuel, il retourne l’e-mail et la pièce jointe téléchargée correctement.
Informations sur votre configuration n8n
- Version n8n : 2.0.3
- Base de données (par défaut : SQLite) :
- Paramètre EXECUTIONS_PROCESS de n8n (par défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : Docker
- Système d’exploitation :
Je n’ai pas d’expérience avec le déclencheur IMAP en particulier, donc je ne peux rien affirmer concernant ce qui est lié à IMAP dans ce que tu as écarté.
Une chose basique que je ne vois pas mentionnée cependant; le workflow est-il activé Active (et pas seulement enregistré/publié)?
Les exécutions manuelles « Execute Workflow » fonctionnent indépendamment de ce commutateur, mais les déclencheurs de production ne se déclenchent que lorsque le workflow est véritablement actif.
J’ai moi-même rencontré cette distinction au début avec un autre type de déclencheur, donc je voulais vérifier que ce n’était pas la même chose ici avant que tu approfondisses les causes spécifiques à IMAP.
Bonjour @TrinhNhatHuy
En regardant le JSON que vous avez fourni, votre nœud Email Trigger (IMAP) n’est connecté à aucun autre nœud: "connections": { "Email Trigger (IMAP)": { "main": [ [] ] } }
Dans n8n, il existe une différence importante entre « Exécution manuelle » et « Exécution en production »:
- Exécution manuelle: Lorsque vous cliquez sur « Exécuter le workflow », n8n exécute le nœud spécifique avec lequel vous interagissez et vous montre les données qu’il a récupérées. Cela fonctionne parce que vous demandez essentiellement au nœud: « Qu’est-ce que tu trouverais maintenant? »
- Exécution en production: Lorsque le workflow est publié, le déclencheur attend un événement. Si le déclencheur se déclenche mais n’est connecté à aucun nœud ultérieur, n8n peut ne pas créer un enregistrement d’exécution dans l’historique parce qu’il n’y avait pas de « workflow » à traiter réellement — le déclencheur s’est déclenché, mais n’avait nulle part où envoyer les données.
Essayez de connecter le Email Trigger à un simple nœud No-Op (Wait ou Code) ou un nœud Discord/Slack/Email, puis publiez-le à nouveau.
En complément du point de kjooleng (un déclencheur déconnecté est la cause la plus courante ici) — si le câbler à un nœud ne le résout pas, deux choses spécifiques à IMAP qui ne surviennent qu’en production, puisque « Execute » manuel ne les active jamais :
1. Basculez le workflow Actif off, puis on à nouveau. Le déclencheur IMAP n’ouvre sa connexion polling/IDLE que lorsque le workflow est activé. Si cette connexion n’a pas été rétablie après votre dernière publication — ou si le serveur mail a interrompu la session idle — le déclencheur reste silencieux et ne consigne aucune exécution. Désactiver et réactiver force n8n à la rouvrir. Cela le résout plus souvent qu’on ne le pense.
2. Assurez-vous qu’une seule instance principale est active. Vous êtes sur Docker : si un second conteneur pointe vers la même base de données, ou si vous êtes en mode file d’attente, les nœuds polling/déclencheur ne s’exécutent que sur l’instance principale — une instance active égarée peut consommer silencieusement le polling.
(Le déclencheur récupère également les messages NON LUS par défaut, mais vous avez déjà exclu cela en envoyant de nouveaux messages non lus.)
S’il est toujours silencieux après réactivation, indiquez-nous s’il s’agit d’une instance unique ou du mode file d’attente et nous pourrons affiner.
Merci de votre soutien ! Dans la version 2.0.3, je ne vois plus de bouton « Actif » pour le workflow. Il n’affiche que l’option de publier le workflow, et je l’ai déjà publié.
Merci @kostasuser01gr, dans mon vrai flux de travail, je l’ai déjà connecté à d’autres nœuds comme ceci
Pour corriger cela, vous devez indiquer à n8n comment traiter l’e-mail une fois qu’il a été récupéré.
- Ouvrez votre nœud Email Trigger (IMAP).
- Recherchez le paramètre Post-process Action.
- Modifiez-le de « Nothing » (Rien) à l’une des options suivantes :
- Mark as Read (Marquer comme lu) : C’est la plus courante. Le workflow se déclenchera sur les e-mails « Unread » (Non lus), et une fois déclenché, il les marque comme « Read » (Lu) pour qu’ils ne soient pas traités à nouveau.
- Move to Folder (Déplacer vers un dossier) : Déplacez l’e-mail vers un dossier « Processed » (Traité). C’est la méthode la plus fiable pour les environnements de production.
- Enregistrez et publiez à nouveau le workflow.
bonjour @nathan3, @kjooleng, merci pour votre réponse. J’ai essayé votre première suggestion en dépubliant puis en republiant le workflow, et cela a fonctionné.
Ma préoccupation est de savoir comment je peux détecter ce problème à l’avenir. Y a-t-il un moyen de surveiller si le déclencheur IMAP a cessé de recevoir des e-mails, pour que je sache quand le workflow doit être dépublié et republié ?
Je préférerais une solution plus fiable que de vérifier manuellement le workflow, surtout si la connexion IMAP peut être interrompue silencieusement sans créer de journaux d’exécution.
Vous pouvez créer un nouveau flux de travail qui s’exécute sur un Déclencheur planifié (par exemple, toutes les 1 heure).
- Étape 1 : Lisez l’horodatage « Dernière exécution » de votre base de données/Google Sheet/KV Store.
- Étape 2 : Utilisez un Nœud IF pour vérifier :
Is (Current Time - Last Run Time) > 2 hours?
- Étape 3 : Si True, envoyez-vous une alerte urgente (Slack, Telegram ou Email) disant : « CRITICAL: Email Workflow has not processed an email in 2 hours. Check IMAP connection. »
Si votre fournisseur de messagerie le supporte (par exemple, Gmail via Pub/Sub), le passage d’un scrutation IMAP à une approche Webhook basée sur le push est 100 % plus fiable car n8n n’a pas besoin de maintenir une connexion socket constamment ouverte ; le serveur indique à n8n quand il y a du courrier.
Pour ajouter une chose que personne n’a encore mentionnée — en plus du watchdog de kjooleng, il y a un levier de prévention intégré sur le nœud lui-même.
Sur le nœud Email Trigger (IMAP), ouvrez Options → Force reconnect every X minutes (par défaut 60). Le réduire à ~15-30 fait que n8n ferme périodiquement et rétablit la connexion IMAP, afin qu’une socket tombée silencieusement se répare d’elle-même sans que vous ayez à dépublier/republier. Cela résout le cas « la connexion meurt silencieusement » à la source, tandis que la vérification du dernier timestamp d’exécution de kjooleng capture tout ce qui passe encore au travers.
Une mise en garde sur ce watchdog de timestamp : « aucun email en X heures » n’équivaut à « cassé » que si vous attendez réellement du trafic régulier. Si le volume entrant est irrégulier, faites que le watchdog envoie un email canary à la boîte à chaque cycle et vérifiez qu’il a été traité — cela teste la connexion indépendamment du courrier réel.
C’est bon à savoir, ça exclut ce que je pensais.
Je ne suis pas familier avec ce qui a changé dans la version 2.0.3 entre l’ancien bouton Actif et Publier, donc je n’ai pas d’autre hypothèse ici.
J’espère que quelqu’un ayant une meilleure visibilité sur le changement 2.0.3 pourra nous dire si l’état publié correspond à quelque chose d’autre, ou si cela mérite son propre rapport de bug.
Salut ! C’est un classique « fonctionne en test, échoue en prod », et c’est incroyablement frustrant.
Puisque ça fonctionne parfaitement lors des tests manuels, tes identifiants et ta configuration de base sont définitivement corrects. Le problème réside dans la différence entre la façon dont n8n gère les tests manuels par rapport à l’interrogation de fond active.
Quand tu cliques sur « Execute Workflow », n8n se connecte, vérifie la boîte de réception une fois, et se déconnecte. Mais quand le workflow est publié (actif), le déclencheur IMAP s’exécute dans une boucle d’interrogation continue en arrière-plan.
En regardant ton JSON de workflow, le principal suspect est l’option forceReconnect: 1. Cela dit à n8n de forcer une toute nouvelle connexion à chaque fois qu’il interroge (généralement toutes les 1 minute). La plupart des fournisseurs de messagerie considéreront ce cycle rapide de connexion/déconnexion depuis une seule adresse IP comme suspect et limiteront temporairement le débit ou supprimeront silencieusement les connexions en arrière-plan.
Voici le plan d’action étape par étape pour corriger cela :
1. Ajuste ou supprime forceReconnect
- Ouvre ton nœud Email Trigger (IMAP).
- Sous Options, change
Force Reconnect de 1 à un nombre beaucoup plus élevé (comme 10 ou 20), ou supprime complètement l’option si tu n’en as pas explicitement besoin.
- Enregistre et réactive le workflow, puis envoie un nouvel e-mail de test.
2. Vérifie les journaux Docker en arrière-plan
Puisque le déclencheur ne s’active jamais avec succès en production, tu ne verras aucune erreur dans l’onglet Executions de l’interface n8n. Les erreurs se produisent dans le processus en arrière-plan.
- Connecte-toi en SSH à ton hôte RHEL et exécute :
docker logs <nom_de_ton_conteneur_n8n>
- Cherche les délais d’expiration de connexion ou les blocages d’authentification spécifiquement liés à
emailReadImap.
3. Envisage de mettre à jour n8n
Tu es actuellement sur la version 2.0.3. De nombreuses corrections de stabilité concernant l’interrogation en arrière-plan et les déclencheurs actifs ont été apportées depuis les premières versions 2.x. La mise à niveau vers une version stable plus récente est hautement recommandée si l’ajustement du paramètre de reconnexion ne résout pas le problème.
@TeSIdrah pour répondre à votre question : dans la v2.0.3, « Publish » est fonctionnellement équivalent à l’ancien curseur « Active » — le workflow s’exécute en mode d’interrogation en arrière-plan de la même manière. Le renommage était purement au niveau de l’interface utilisateur, donc le comportement du déclencheur IMAP n’est pas censé changer entre les versions.
Si le déclencheur fonctionne manuellement mais pas après la publication, les causes les plus probables sont :
forceReconnect défini sur 1 (comme l’a souligné n8n_Sensei) — corrigez cela en premier- Le délai d’inactivité IMAP étant supprimé silencieusement par le serveur de messagerie après que la connexion reste ouverte trop longtemps
Une vérification rapide : après la publication, allez à Executions et filtrez par votre workflow. Si vous voyez zéro exécutions de production pour tout e-mail entrant, la connexion meurt silencieusement. Si vous voyez des exécutions mais qu’elles génèrent des erreurs, les journaux vous diront ce qui se passe.
Vérifiez le journal d’exécution de production et confirmez que le flux de travail publié est actif sur la même instance qui contient l’identifiant IMAP. Je vous recommande également de tester avec un nouveau message non lu après la publication, car l’exécution manuelle peut utiliser un chemin de déclenchement différent.