Ich hatte ein Problem mit einem Gmail-Autoantwort-Workflow, der anfing, eine Antwort immer wieder an dieselbe Adresse zu senden, sogar nachdem ich alle Knoten deaktiviert hatte (was wirklich seltsam ist).
So funktioniert es:
Unsere E-Mail wird von unserem Partner bei E-Mails, die an Leads gesendet werden, in CC genommen. Der erste Knoten wird einmal pro Stunde ausgelöst, um E-Mails von der E-Mail-Adresse unseres Partners zu finden, mit Filterung nach der Betreffzeile UND nur nach ungelesenen E-Mails. Dann werden Variablen für die E-Mail-Adresse des Empfängers und die Nachrichten-ID gesetzt. Der nächste Knoten kennzeichnet die Nachricht als gelesen, indem er die ID verwendet. Dann antwortet der nächste Knoten im Thread mit der Thread-ID vom Trigger. Dann wird der Lead zu einer Tabelle hinzugefügt und ein Lead in Zoho erstellt.
Es begann vor einer Woche, wir haben es erst kürzlich bemerkt. Das Seltsamsate ist, dass es weiterhin E-Mails gesendet hat, auch nachdem wir die Knoten deaktiviert haben, also haben wir den Workflow einfach entfernt, um sicher zu gehen.
Ich habe einige ähnliche Threads hier gesehen, aber das scheint ein bisschen anders zu sein. Wir filtern ungelesene Nachrichten heraus, aber der Workflow zieht dieselbe E-Mail immer wieder auf.
@Arsen Der “still sending after deactivation”-Teil sind warteschlangenbefehle, die sich ausgelöst haben, bevor die Deaktivierung wirksam wurde — n8n Cloud bricht laufende Ausführungen nicht ab, sondern stoppt nur NEUE Trigger. Die 50 Antworten sind also 50 aufgestaute Ausführungen, die sich bereits in der Warteschlange befanden.
Die Grundursache für die 50 ist wahrscheinlich die Reihenfolge — wenn der Schritt „als gelesen markieren
Willkommen in der n8n-Community @Arsen
Bitte aktualisieren Sie Ihre Instanz über das Admin-Panel auf v2.21.7.
Kehren Sie zum Workflow zurück, deaktivieren Sie die Knoten und aktivieren Sie sie erneut. Veröffentlichen Sie
führen Sie aus und geben Sie uns das Ergebnis zurück, wenn möglich.
Noch eine seltsame Sache – die E-Mail wurde 50-mal an dieselbe Person versendet, aber die Adresse dieser Person wurde nur einmal in der Tabelle hinzugefügt
Das eigentliche Problem ist eine Race Condition zwischen dem Trigger und dem mark-as-read Node.Gmail gibt ungelesene E-Mails zurück basierend auf dem Status zum Zeitpunkt der API-Anfrage. Wenn der Trigger die E-Mail holt und der mark-as-read Node noch nicht ausgeführt hat, kann die nächste Ausführung dieselbe E-Mail nochmal holen, besonders wenn Ausführungen sich überlappen.
Die beste Lösung ist, dass du nach dem Trigger einen deduplizierenden Filter basierend auf der Message-ID hinzufügst. Speichere verarbeitete Message-IDs in einem Static Data Store oder einer Google Sheet. Vor der Verarbeitung prüfen ob die ID bereits existiert.
Wenn die Autoantwort ausgeschaltet ist. Dann befolge bitte diese Schritte.
Teste es in einem kleinen Umfang, indem du den Workflow duplizierst und nur die Einstellungen änderst, anstatt von der Partner-E-Mail zu lesen, lies stattdessen von deiner E-Mail (nicht die BCC)
Behalte alle deine Einstellungen und nutze eine E-Mail (neue E-Mail, von der du senden oder empfangen kannst zum Testen)
Reduziere die Auslösezeit auf 1 Minute nur zum Testen
Halte beim Beantworten der Nachricht an (da dies das Showstopper-Problem ist)
Stelle sicher, dass du einen schrittweisen Flow-Test durchführst (vor dem Veröffentlichen)
Wenn es gut funktioniert hat, dann veröffentliche den kleinen Umfang
teste es erneut in der Produktion, und es sollte funktionieren!
Genau, wenn dieselbe E-Mail immer wieder im Spreadsheet auftaucht
bestätigt das das Problem.
Die Lösung ist ein Code-Node direkt nach dem Trigger, der prüft ob
die Message-ID bereits verarbeitet wurde. Falls du Hilfe bei der
genauen Einrichtung brauchst, helfe ich dir gerne!
@Arsen: Zeigen 49 dieser Läufe in den Ausführungsprotokollen einen Fehler auf dem Knoten unmittelbar nach dem Antwortenknoten? Wenn ja, hat der Workflow die Antwort erfolgreich abgeschlossen, ist dann aber downstream auf einen Fehler gestoßen. Da n8n die E-Mail jedoch bereits versendet hatte, war der Schaden angerichtet.
Das ist genau das Problem: Es gab KEINE Fehler bei den Ausführungen, und jede Ausführung wurde erfolgreich abgeschlossen. Die E-Mail wurde nicht immer wieder zur Tabelle hinzugefügt. Sie wurde einmal hinzugefügt, und das war’s
Also wenn keine Fehler da sind und die Tabelle nur einen Eintrag hat, liegt das Problem wahrscheinlich daran, dass die Antwort deines Partners die E-Mail in Gmail wieder als ungelesen markiert. Dadurch pullt der Trigger sie jede Stunde erneut. Füge als Lösung direkt nach dem Trigger einen Filter ein der prüft ob die E-Mail in den letzten 2 Stunden eingegangen ist. Alte E-Mails können dann nicht mehr in die Schleife geraten.
Eigentlich antwortet unser Partner nicht, wir sind es, die auf die E-Mails antworten. Wir antworten nur dem Empfänger und lassen unseren Partner sowieso raus. Deshalb ist es wirklich seltsam
Ok dann fällt die Partner-Theorie weg. Mein nächster Verdacht ist, dass Gmail die E-Mail nach deiner Antwort intern wieder als ungelesen markiert, weil der Thread aktualisiert wird.
Füge als Test nach dem “Mark as Read” Node eine kurze Wartezeit von 1-2 Sekunden ein, dann nochmal “Mark as Read”. Manchmal braucht Gmail einen Moment bis die Änderung greift.
ok, ich schau mir die Workflow-Screenshots an — Gmail Trigger Filter (unread + partner sender + subject), Mark as Read mit $('Edit Fields').item.json.id, Reply mit $('Gmail Trigger').item.json.threadId. Das sieht alles in Ordnung aus.
wenn 50 separate stündliche Ausführungen immer wieder dieselbe Nachricht als ungelesen finden UND mark-as-read meldet Erfolg, dann wird die E-Mail zwischen den Abfragen von etwas wieder auf ungelesen zurückgesetzt — könnte ein Gmail-Filter-Rule sein, die mobile App oder ein anderer IMAP-Client, der die Inbox anfasst. Das kannst du nicht von innen heraus in n8n beheben. Was du ABER beheben kannst, ist den Workflow so einzurichten, dass er die gleiche Reply zweimal nicht sendet, unabhängig vom Read-Status.
füg diesen Code-Node zwischen den Gmail Trigger und Edit Fields ein. Er speichert verarbeitete Message-IDs in n8ns statischen Workflow-Daten, damit Duplikate über Ausführungen hinweg gefiltert werden:
$getWorkflowStaticData('global') bleibt über Ausführungen hinweg in n8n Cloud erhalten, also die ID-Liste wird persistent. Beim ersten Mal, dass eine Nachricht durchkommt, wird sie geloggt + weitergeleitet; beim zweiten Mal wird sie vom Filter fallen gelassen und der Workflow bricht auf null Items ab. Jetzt sendest du die Reply genau einmal pro unique Message-ID, selbst wenn Gmail es immer wieder auf ungelesen zurückmarkiert.
