Erreur de déclenchement Gmail

Décrivez le problème/l’erreur/la question

Problème du nœud Gmail Trigger : j’éprouve un problème avec mon flux de travail utilisant le nœud Gmail Trigger dans la version 2.20.7 de n8n, et c’était la même chose pour 2.20.6. Mon flux de travail est configuré pour interroger les e-mails non lus toutes les minutes, j’ai maintenant défini à 5 minutes pour ne pas surcharger le nombre d’exécutions, mais il compte les exécutions même quand aucun e-mail non lu n’est trouvé, ce qui l’enregistre également comme une erreur dans l’onglet d’exécution. Ce comportement est différent de la version 2.16, où de tels cas n’étaient pas comptabilisés comme des exécutions. Comment puis-je configurer mon flux de travail pour qu’il ne compte pas les exécutions quand aucun e-mail n’est trouvé ? Pour l’instant, je capture le type d’erreur spécifique et je la définis à zéro, ma seule préoccupation est qu’elle augmente mon nombre d’exécutions et de cette manière je dépasserai la limite mensuelle. J’ai remarqué ce problème après ma mise à jour hier de 2.16.# à 2.20.6 comme dernière version stable et aujourd’hui à 2.20.7 comme dernière version stable.

Quel est le message d’erreur (le cas échéant) ?

Pas d’erreur spécifique, cela affiche simplement : Problème dans le nœud « Gmail Trigger » et dans d’autres informations cela affiche les détails de la requête de recherche comme cause

[
{
“trigger”: {
“error”: {
“name”: “IsolateError”,
“cause”: {
“q”: “=from:@domain.com -from:group@domain.com newer_than:1d”,
“readStatus”: “unread”
}
},
“mode”: “trigger”
},
“workflow”: {
“id”: “#####”,
“name”: “Gmail Workflow Name”
}
}
]

Veuillez partager votre flux de travail

Veuillez noter que j’ai remplacé les ID et les noms ainsi que les adresses e-mail par des données fictives ou #### pour ne pas accidentellement divulguer des détails confidentiels.

(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le flux de travail.)
{
  "nodes": [
    {
      "parameters": {
        "pollTimes": {
          "item": [
            {
              "mode": "everyX",
              "value": 5,
              "unit": "minutes"
            }
          ]
        },
        "maxResults": 1,
        "filters": {
          "q": "==from:@domain.com -from:group@domain.com newer_than:1d",
          "readStatus": "unread"
        }
      },
      "type": "n8n-nodes-base.gmailTrigger",
      "typeVersion": 1.4,
      "position": [
        656,
        1104
      ],
      "id": "#####,
      "name": "Group Gmail Trigger",
      "alwaysOutputData": false,
      "notesInFlow": false,
      "credentials": {
        "gmailOAuth2": {
          "id": "####",
          "name": "Gmail Group Support Gmail2"
        }
      }
    }
  ],
  "connections": {
    "Group Gmail Trigger": {
      "main": [
        []
      ]
    }
  },
  "pinData": {},
  "meta": {
    "templateCredsSetupCompleted": true,
    "instanceId": "#####"
  }
}

Partager la sortie renvoyée par le dernier nœud

Détails de l’erreur
Autres informations
Version de n8n
2.20.7 (Cloud)
Cause de l’erreur
{ “q”: “=from:@domain.com -from:group@domain.com newer_than:1d”

Informations sur votre configuration n8n

  • Version de n8n : 2.20.7
  • 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) : n8n cloud
  • Système d’exploitation :

J’attends avec intérêt vos commentaires ou si c’est une erreur qui doit être corrigée par ceux qui maintiennent le nœud Gmail Trigger ou la version de n8n.

Merci,

Nidhi Patel

5x12x24x31 = 44640 exécutions par mois

Je crois que c’est le comportement correct puisque le flux de travail est déclenché

Merci, @kjooleng - mais ce n’était pas le cas plus tôt, et d’un autre côté, cela le génère comme une erreur, ce qui est également un comportement inhabituel. Avez-vous des idées à ce sujet ?

Merci,

NP

Salut @nidhi-patel ! Bonne question sur la partie erreur spécifiquement.

Sur le changement de comportement depuis la v2.16 : tu as raison, cela a changé. Dans les versions antérieures, les triggers de polling qui ne trouvaient aucun résultat se fermaient correctement sans enregistrer une exécution. À partir de la v2.17+, chaque cycle de polling est enregistré comme une exécution, peu importe s’il a trouvé quelque chose ou non. C’était un changement volontaire pour l’observabilité, bien qu’il ait l’effet secondaire que tu vois sur les plans cloud avec des limites d’exécution.

Sur l’erreur lancée : l’IsolateError que tu vois n’est probablement pas une erreur de l’API Gmail, mais plutôt n8n qui lance une erreur en interne parce que le node a reçu 0 résultats et la gestion des erreurs du trigger surface cela comme un événement d’erreur. Quelques choses à essayer :

  1. Dans les paramètres du node Gmail Trigger, vérifie s’il y a une option “On Error” (À l’erreur). Définis-la sur “Continue” si disponible.
  2. Alternativement, passe du node Gmail Trigger à un Schedule Trigger qui s’exécute toutes les 5 minutes, suivi d’un node Gmail en mode “Get Many” avec ta requête de filtre. Puis ajoute un node IF pour vérifier si le tableau de résultats est vide avant de continuer. Cela te donne un contrôle total et le schedule trigger lui-même ne lance pas d’erreur sur les résultats vides.

L’approche Schedule + Gmail Get Many est en fait plus flexible à long terme, car tu peux ajouter une logique de nouvelle tentative, filtrer plus précisément et c’est plus facile à déboguer.

J’espère que cela t’aide !

Merci @nguyenthieutoan, j’apprécie l’explication. J’ai déjà mis en place ce que tu as suggéré, mais je ne suis pas content de voir une erreur quand il n’y a « Aucun nouvel email » avec le nœud Gmail Trigger. Le truc amusant, c’est qu’il dit que la requête en est la cause, donc le message d’erreur est incorrect et trompeur aussi. J’ai passé beaucoup de temps à vérifier si le format de la requête avait changé chez Google.

Je pense qu’au minimum, cela ne devrait pas être enregistré comme une erreur, puisque ce n’en est pas une. Et peut-être qu’une autre approche serait mieux – comme un Info ou même un Warning, ou simplement l’enregistrer. L’autre problème pour moi, c’est que cela compte comme une exécution et qu’il n’y a pas de rupture propre. Cela me force indirectement à accepter une mise à niveau du plan, ou à opter pour l’auto-hébergement. Je pense que c’est un point très important pour moi dans ce scénario. Comme je l’ai mentionné, j’étais sur le nœud Gmail Trigger v1.2, donc j’ai mis à jour vers v1.4, mais tout ce qu’il a fait, c’est ajouter un paramètre de nombre maximum d’éléments par sondage. Aussi, avant la mise à jour, le journal des modifications ne montrait pas beaucoup de détails sur le fait que je tomberais dans ce problème. Je n’ai pas pu tester avant de mettre à jour, c’était une grosse erreur.

La configuration que j’ai est :

1 : Nœud Gmail Trigger : Paramètres → On Error : arrêter le workflow, et un nœud qui vérifie s’il a un ID légitime. Ensuite, j’utilise l’ID pour récupérer le message complet via une API pour le traiter davantage.

→ La prochaine chose que je peux essayer est d’ajouter une boucle, pour que je puisse parcourir les nouveaux emails qui n’ont pas été traités et repousser les exécutions des déclencheurs de 5 minutes à 30 minutes pour diminuer les exécutions, si cela est approuvé en interne.

2 : Workflow d’erreur auquel j’ai dû ajouter un scénario spécial pour ne pas déclencher de notification de suivi sur les canaux suivants et corriger l’erreur.

Je ne suis pas sûr, mais je ne semble pas pouvoir trouver un moyen de revenir à une version antérieure.

Maybe l’équipe n8n peut évaluer et voir si cela a de la valeur :

→ Pour garder les journaux d’exécution non encombrés et ne pas enregistrer comme une erreur quand aucun email n’est trouvé, puisqu’en réalité ce n’en est pas une. De cette façon seulement, cela aidera à une enquête significative sur les véritables erreurs, quand nécessaire.

→ Pour que le nœud Gmail Trigger ait une rupture propre

→ Ne pas compter comme une exécution quand il n’y a pas d’erreur, puisqu’en réalité c’est le webhook qui vérifie les nouveaux emails. L’ensemble du flux n’a pas besoin d’être exécuté.

De toute façon, merci pour les détails que tu as partagés. J’apprécie. S’il te plaît, fais-moi savoir s’il y a une autre approche que je devrais essayer.

Cordialement,

NP

Peux-tu faire cela ?

La liste déroulante devrait te permettre de changer de version

Vous avez soulevé des points vraiment valides ici, NP, et honnêtement, ce genre de décomposition détaillée est exactement ce que l’équipe n8n a besoin d’entendre.

Vous avez tout à fait raison que consigner un scénario « aucun nouvel e-mail » comme une erreur est trompeur. Ce n’est pas une erreur en aucun sens significatif, c’est juste un cycle d’interrogation qui n’a rien trouvé. Le fait que cela compte également comme une exécution et que le message d’erreur pointe vers « query » comme cause rend les choses encore plus confuses et a de véritables implications de coûts sur les plans cloud.

Quelques points qui pourraient vous aider en attendant :

Sur le comptage des erreurs : Si vous basculez votre Gmail Trigger « On Error » de « Stop Workflow » à « Continue » (ignorer les erreurs), le cycle d’interrogation se produit toujours mais ne s’affichera pas comme une exécution échouée dans votre workflow d’erreur. Cela réduit le bruit dans le suivi des erreurs, même si cela ne résout pas le comptage des exécutions lui-même.

Sur la version : Le conseil de @kjooleng concernant la liste déroulante des versions est la bonne approche si vous êtes sur le cloud n8n. Vous pouvez essayer de sélectionner 2.19.5 ou quelle que soit la version qui était stable avant ce changement de comportement.

Plus important encore : Je vous encourage fortement à soumettre cela comme une demande de fonctionnalité/bogue sur GitHub à Issues · n8n-io/n8n · GitHub . Votre explication ici est déjà très claire et bien structurée. Les trois points que vous avez énumérés :

  • Ne pas consigner les interrogations vides comme des erreurs
  • Comportement de rupture nette pour Gmail Trigger
  • Ne pas compter les interrogations sans résultat comme des exécutions

…sont véritablement des améliorations UX raisonnables et l’équipe agit sur les commentaires bien documentés de la communauté. Plus les gens l’apprécient ou le soutiennent, meilleures sont les chances qu’il soit priorisé.

J’espère que cela vous aidera à avancer !

Merci @kjooleng , je n’ai pas la version que vous suggérez, veuillez consulter la capture d’écran ci-jointe..

Faites-moi savoir s’il existe une autre solution.

Cordialement,

NP

Merci @nguyenthieutoan, je vais créer un ticket en fonction de votre suggestion, j’espère que cela aidera à résoudre le problème. En attendant, je vais voir comment je peux réduire la fréquence du déclencheur Gmail.

J’apprécie vos conseils clairs.

Cordialement,

NP

Bonjour @nidhi-patel

J’ai vérifié les problèmes GitHub les plus proches que j’ai pu trouver, et aucun d’entre eux ne semble être ouvert maintenant. Les plus proches sont liés à l’interrogation du déclencheur Gmail, à la gestion des e-mails non lus ou aux différences entre le comportement des déclencheurs manuels et automatiques, mais ils ne décrivent pas ce cas exact où une interrogation vide est enregistrée comme une erreur et comptée comme une exécution. Le point clé que je signalerais est qu’une interrogation vide ne doit pas être comptabilisée ou enregistrée comme une exécution échouée, car « aucun nouvel e-mail » est un état de déclencheur valide, non une erreur opérationnelle.

Excellente remarque de @tamy.santos ! Cette formulation est exacte, « aucun nouvel email » n’est vraiment qu’un état inactif normal, pas une erreur. Le signaler à GitHub est définitivement la bonne décision, @nidhi-patel.

En attendant, réduire la fréquence de scrutation comme vous l’avez mentionné devrait aider à maintenir votre nombre d’exécutions sous contrôle. Si vous trouvez que les conseils ici vous ont aidé à clarifier la solution de contournement et les prochaines étapes, n’hésitez pas à marquer la réponse la plus utile comme Solution afin que d’autres personnes ayant la même question puissent la trouver rapidement !