Der Workflow beginnt mit einem Trigger, der auf stündliche Intervalle eingestellt ist, sodass genug Zeit vorhanden ist, damit die Aktion des Markierens als gelesen registriert wird. Diese E-Mails wurden über etwa eine Woche verteilt an dieselbe E-Mail-Adresse mit verschiedenen seltsamen Intervallen gesendet
@Arsen, wie steht es mit dieser Frage?
Hast du es geschafft zu lösen? Sag mir Bescheid, wenn deine Instanz auf Version 2.23 läuft und wenn du deine JSON-Datei ohne sensible Daten teilen kannst
Ein Pattern, das sich zusätzlich zum Mark-as-Read-Ansatz lohnt: Speichere jede verarbeitete messageId in einem Google Sheet (oder nutze n8ns Workflow Static Data) und überprüfe es am Anfang jedes Durchlaufs, bevor du etwas anderes machst. Selbst wenn Gmails Lese-/Schreibvorgänge einen Timing-Fehler haben, fängt die Deduplication-Überprüfung ihn ab.
Der Ablauf wäre: E-Mails abrufen → für jede Nachricht überprüfen, ob ihre ID bereits in deinem Log existiert → überspringen, falls ja, ansonsten Antwort versenden und ID zum Log hinzufügen. Das macht den Workflow idempotent, unabhängig davon, was Gmails Lesezustand sagt. Static Data ist die einfachste Option, wenn du keinen externen Speicher möchtest – $getWorkflowStaticData('global').processedIds als Array, das du nach jeder erfolgreichen Antwort hinzufügst.
Der Filter für ungelesene E-Mails ist das Problem. Wenn n8n auf den Thread antwortet, markiert Gmail diese Antwort als neue ungelesene Nachricht, also nimmt Ihr Trigger den gleichen Thread in der nächsten Stunde wieder auf und die Schleife setzt sich fort.
Lösung: Fügen Sie nach dem Antwortschritt einen Gmail-Knoten „Label hinzufügen