When I add an IMAP node to check a subfolder, the new mails are marked as read, due to the config, but the node has not triggered. When I “unread” them and trigger the node manually, it works. Just automatic trigger is not working correctly
As mentioned, mails are marked read by the node, it just does not trigger when enabled. It triggers only when running manually. Hence I assume filters and folder name are correct.
There is no other client marking the mails read.
The IMAP server is Fastmail.
I also have issues with the IMAP trigger on n8n stable @ docker. In manual test it sort of randomly succeeds, than again listening forever without input when adding new mails to the source folder and also not working when activated …
I’m facing the same issue now. In addition, my workflow is running when I’m clicking on ‘Execute workflow’ but it’s neither getting published nor unpublished.
You can unarchive a workflow by following these steps. Go to workflows. On top right, you see ‘filter’ icon (beside ‘search’ and ‘create folder’ icons). Click on it. You will see a check box with label ‘Show archived workflows’. Check the box and you’ll see archived workflows. open the corresponding workflow, unarchive it (just like you archived it). stop the trigger and delete it if you wish to.
I’m using self hosted version with Hostinger and it isn’t working for me too. When I add credentials it shows “Connection tested successfully” but node is not triggering. I’ve tested it with “INBOX” and “INBOX.subfolder”, Custom Email Rules both [“UNSEEN”] and [“ALL”]
And it seems that the Customer **(Un)**Success department is not very interested in fixing the IMAP problem, or even showing up here to provide any update or feedback.
Danke, dass ihr das gemeldet habt — wir haben mehrere Fehler im IMAP Email Trigger Node identifiziert und behoben, die dieses Verhalten verursachen könnten.
Was ist passiert: Wenn der IMAP-Server bestimmte E-Mail-Formate zurückgab, konnte der Trigger stillschweigend abstürzen und den Workflow im Hintergrund deaktivieren. E-Mails würden trotzdem als gelesen markiert (da dies vor dem Absturz passierte), aber der Workflow würde sich nie ausführen. Dies betraf besonders das Simple-Format — ein Wechsel zu Resolved konnte das Problem umgehen, wie einige von euch entdeckt hatten.
Was wir behoben haben:
Eine Sicherheitsprüfung für fehlerhaft formatierte E-Mail-Header im Simple-Format hinzugefügt — zuvor würde ein fehlender Header den Trigger zum Absturz bringen und den Workflow stillschweigend deaktivieren
Die Mark-as-Read-Logik behoben, um nur E-Mails zu kennzeichnen, die tatsächlich verarbeitet und an den Workflow übermittelt wurden
Doppelte Verarbeitung beim Empfang großer E-Mail-Batches (20+) behoben
Concurrency-Schutz gegen schnelle E-Mail-Benachrichtigungen hinzugefügt
Workaround bis zum Fix verfügbar ist: Falls ihr dieses Problem immer noch habt, versucht, den Format-Parameter zu Resolved zu wechseln. Stellt auch sicher, dass die Option Force Reconnect Every Minutes aktiviert ist (unter Options) — dies hilft bei IMAP-Servern, die Benachrichtigungen über neue E-Mails nicht zuverlässig senden.
Der Fix befindet sich in PR #30375 und sollte bald live gehen. Danke für die detaillierten Berichte!
Schön zu sehen, dass sich das n8n-Team damit auseinandersetzt! Danke an @garrit für die ausführliche Erklärung, was tatsächlich passiert ist, und für die Lösung in PR #30375.
Hier ist eine kurze Zusammenfassung der wichtigsten Punkte für alle, die auf diesen Thread stoßen:
Grundursache: Wenn der IMAP-Server bestimmte fehlerhafte E-Mail-Header zurückgab, stürzte der Trigger stillschweigend ab und deaktivierte den Workflow im Hintergrund. E-Mails wurden weiterhin als gelesen markiert, aber nichts wurde ausgeführt.
Workaround (bis zum Versand der Lösung):
Wechseln Sie den Format-Parameter zu Resolved statt Simple
Aktivieren Sie Force Reconnect Every Minutes unter Options
Permanente Lösung: Enthalten in PR #30375. Beachten Sie die Changelog-Einträge für die Version, in der sie implementiert wird, und aktualisieren Sie, sobald sie verfügbar ist.
Großartig, wie die Community hier hartnäckig daran gearbeitet hat, dass das gründlich untersucht wurde!