J’ai rencontré un problème avec un workflow de réponse automatique Gmail qui a commencé à envoyer une réponse à la même adresse encore et encore, même après désactivation de tous les nœuds (ce qui est vraiment étrange).
Voici comment ça fonctionne :
Notre email est en copie d’un partenaire sur les emails envoyés aux prospects. Le premier nœud se déclenche une fois par heure pour trouver les emails de l’adresse email de notre partenaire, en filtrant par la ligne d’objet ET en ne ciblant que les emails non lus. Ensuite, il définit les variables pour l’adresse email du destinataire et l’identifiant du message. Le nœud suivant marque le message comme lu en utilisant l’identifiant. Ensuite, le nœud suivant répond dans la conversation en utilisant l’identifiant du fil d’attente du déclencheur. Puis il ajoute le prospect à un tableau et crée un prospect dans Zoho.
Cela a commencé il y a une semaine, et nous l’avons remarqué récemment. La partie la plus étrange est qu’il a continué à envoyer des emails même après désactivation des nœuds, c’est pourquoi nous avons dépublié le workflow juste pour être sûr.
J’ai vu des fils de discussion similaires ici, mais celui-ci semble un peu différent : nous filtrons les messages non lus, mais il récupère toujours le même email encore et encore.
@Arsen la partie « toujours envoyer après la désactivation » concerne les exécutions en file d’attente qui se sont déclenchées avant la désactivation — n8n Cloud n’annule pas les exécutions en cours, il arrête juste les NOUVEAUX déclencheurs. donc les 50 réponses sont 50 exécutions en attente qui étaient déjà dans la file.
la cause racine des 50 en premier lieu est probablement l’ordre — si l’étape mark-as-read échoue ou s’exécute lentement, le prochain sondage horaire voit le même message non lu et déclenche une autre réponse. est-ce que l’étape mark-as-read a réellement réussi dans chaque journal d’exécution, ou a-t-elle échoué silencieusement ?
Corrigez-moi si je me trompe, le mode principal n’est-il pas utilisé par la plupart des plans Standard Cloud (Starter/Pro)?
Si c’est le cas, il n’y aura pas de travaux en file d’attente.
Bienvenue dans la communauté n8n @Arsen
Veuillez mettre à jour votre instance vers la v2.21.7 via le panneau d’administration.
Revenez au flux, désactivez les nœuds et réactivez-les. Publiez.
Mettez en exécution, et renvoyez-nous le résultat si possible.
Aussi une chose bizarre - l’email a été envoyé à la même personne 50 fois, mais l’adresse de cette personne n’a été ajoutée à la feuille de calcul qu’une seule fois
Tu peux sélectionner tous les nœuds avec Ctrl+A et les copier avec Ctrl+C. Ensuite, colle le contenu après avoir appuyé sur le bouton </> avec Ctrl+V.
Je vois que ton déclencheur Gmail contient plus d’un élément, ce qui peut causer des problèmes si les nœuds suivants n’étaient pas configurés correctement
Le véritable problème est une condition de concurrence entre le trigger et le nœud mark-as-read. Gmail retourne les e-mails non lus en fonction du statut au moment de la requête API. Si le trigger récupère l’e-mail et que le nœud mark-as-read n’a pas encore été exécuté, l’exécution suivante peut récupérer la même e-mail à nouveau, surtout si les exécutions se chevauchent.
La meilleure solution est d’ajouter un filtre de déduplication basé sur l’ID de message après le trigger. Stocke les ID de messages traités dans un Static Data Store ou une Google Sheet. Avant le traitement, vérifie si l’ID existe déjà.
Bonjour @Arsen
Peux-tu vérifier les paramètres de réponse automatique Gmail ?
Tu vas à Gmail > Paramètres > Général > Répondeur automatique (Répondeur automatique désactivé/activé).
Si la réponse automatique est désactivée. Ensuite, assure-toi de suivre ces étapes.
Testé-le sur un petit périmètre en dupliquant le flux de travail, en changeant simplement les paramètres au lieu de lire l’e-mail du partenaire pour lire ton e-mail (autre que celui en copie cachée)
Garde tous tes paramètres et utilise un seul e-mail (nouvel e-mail à partir duquel tu peux envoyer ou recevoir pour tester)
Réduis le délai d’activation à 1 minute pour le test uniquement,
Arrête-toi à la réponse au message (puisque c’est le blocage)
Assure-toi de faire un test de flux étape par étape (avant de publier)
Si ça fonctionne bien, alors publie le petit périmètre
teste-le à nouveau en production, et ça devrait fonctionner !
Exactement, si le même e-mail réapparaît constamment dans le spreadsheet, cela confirme le problème.
La solution est un nœud de code directement après le déclencheur, qui vérifie si le Message-ID a déjà été traité. Si tu as besoin d’aide pour la configuration exacte, je suis ravi de t’aider !
@Arsen dans les journaux d’exécution, est-ce que 49 de ces exécutions montrent un échec/erreur sur le nœud immédiatement après le nœud de réponse ? Si oui, le workflow complétait la réponse avec succès, puis rencontrait une erreur en aval, mais comme n8n avait déjà envoyé l’email, les dégâts étaient faits.
qu’est-ce que le déclencheur Gmail retourne quand il interroge ?
C’est exactement ça ; il n’y avait AUCUNE erreur dans les exécutions, et chaque exécution s’est déroulée avec succès. L’e-mail n’était pas ajouté plusieurs fois au tableur. Il a été ajouté une fois, et c’est tout
Donc si aucune erreur n’est présente et que le tableau ne contient qu’une seule entrée, le problème provient probablement du fait que la réponse de ton partenaire marque l’e-mail comme non lue dans Gmail. De cette façon, le déclencheur la récupère à nouveau chaque heure. Comme solution, ajoute un filtre directement après le déclencheur qui vérifie si l’e-mail a été reçue au cours des 2 dernières heures. Les anciens e-mails ne peuvent ainsi plus se retrouver dans la boucle.
En fait, ce n’est pas notre partenaire qui ne répond pas, c’est nous qui répondons aux emails. Nous répondons uniquement au destinataire et nous excluons notre partenaire de toute façon. C’est pour ça que c’est vraiment bizarre
Ok donc la théorie des partenaires est écartée. Mon prochain soupçon est que Gmail remarque l’e-mail en interne après ta réponse parce que le fil de discussion est mis à jour.
Ajoute comme test après le nœud « Mark as Read » une courte pause de 1-2 secondes, puis à nouveau « Mark as Read ». Parfois, Gmail a besoin d’un moment pour que le changement prenne effet.
ok en regardant les screenshots du workflow — Gmail Trigger avec filtre (non lu + sender partenaire + subject), Mark as Read utilisant $('Edit Fields').item.json.id, Reply utilisant $('Gmail Trigger').item.json.threadId. tout ça a l’air bon.
si 50 exécutions horaires séparées trouvent toutes le MÊME message non lu ET que mark-as-read continue de rapporter un succès, quelque chose remet le mail à non lu entre les sondages — ça pourrait être une règle de filtre Gmail, l’app mobile, ou un autre client IMAP qui touche à la boîte de réception. tu vas pas corriger cette cause racine de l’intérieur de n8n. ce que tu PEUX corriger c’est faire en sorte que le workflow refuse d’envoyer la même réponse deux fois quel que soit l’état de lecture.
dépose ce nœud Code entre Gmail Trigger et Edit Fields. il persiste les IDs de messages traités dans les données statiques du workflow n8n donc les doublons se font filtrer à travers les exécutions :
$getWorkflowStaticData('global') persiste à travers les exécutions sur n8n Cloud donc la liste d’IDs se conserve. la première fois qu’un message arrive il se fait enregistrer + passe en aval ; la deuxième fois le filtre le retire et le workflow court-circuite à zéro items. maintenant même si Gmail continue de remettre non lu, tu envoies la réponse exactement une fois par ID de message unique.
