Hey @MortgageRockstar,
docker logs [container_name] would be the bit that we would be interested in, Normally it would show some kind of error if a workflow just stops.
It might be worth revisiting the logging again to see if we can work out why that is failing or maybe the mail server has something in the logs that would be useful.
No errors, @Jon. The docker log just shows the active workflows including the workflow in question (see below). There are no errors yet no executions in the n8n execution log with incoming emails.
It appears to be an issue with the IMAP Email node itself or IMAP credentials connection (although credentials have always showed in n8n as “connection tested successfully”).
It appears that I am able to get the workflow executing again by de-activating and re-activating the workflow, but that is not optimal.
@MutedJam do you have any thoughts?
I am afraid not, I don’t really have an in-depth understanding of how our IMAP node works.
Hey @MortgageRockstar,
I was just having a chat with @MutedJam and looking through the code for the node, Could you go to Options and add Force Reconnect and leave that as 60 and monitor for a few days and let me know if it helps.
Hi @Jon
I came from this post IMAP Email Node Does Not Trigger Workflow - #12 by Jon, with the same issue as I have mentioned there.
I did what you suggest by activating the “Force Reconnect” with 60s, but this didn’t solved the issue, the trigger goes stuck after a while (but the emails are marked as open…)
In fact, I have also tried by setting up another workflow that deactivate & activates the workflow containing the IMAP trigger, every few hours with a cron in order to “reset” it, but this did not solved the issue with the IMAP trigger neither.
Issue mentioning this workaround (doesn’t worked for me): IMAP Triggers randomly stop processing new messages · Issue #1400 · n8n-io/n8n · GitHub
@Jon, I’ve used the force reconnect option in the past like @pbdco and it didn’t solve the issue. The problem appears to be with the IMAP Email node itself.
Any other suggestions?
As an aside, I applaud the development of n8n. I have to be honest though as someone who has really tried to adopt n8n that it is so wonky and unreliable that it’s not anywhere near a replacement for Zapier which does not have these kinds of issues. That’s disappointing after all the time I’ve devoted to learn the n8n platform. I’m very close to giving up. 
Hey @MortgageRockstar,
I am sure we will be able to win you back 
we had a report from a cloud customer today about a similar issue so we have enabled debug logging on their instance to see if we can capture the issue happening. The tricky bit about issues like this is we need to be able to reproduce it so we can understand why it is breaking and also test any potential fixes.
Hey @Jon it’s good to know you’re into this. Please keep us updated. Thanks!
PS: N8N absolutely rocks! Bugs can be anywhere… even at Zapier! 
@MortgageRockstar
Thanks @Jon, keep it up with the great work guys! 
We encountered the exact same issue. The scenarios where not triggered without any obvious reason. We did not change anything. It happend last sunday and today. We are running a cloudron instance, which got the latest update on sunday morning.
As a workaround, i added a “cron” which triggers every minute. They seem to work more reliable.
Edit: When manually stating the workflow, all unprocessed mails are caught. That’s why i hope the cron will temporally fix this.
Hey There,
This one is really bugging me, Before I was not able to reproduce the issue and now it is fairly consistent which is nice. I have a couple of things to look into then I really want to get this one fixed.
Hi @Jon,
If it helps, this weekend and since the update of n8n to version 0.197.0, 0.197.1 and 0.198.2 the Imap Trigger node causes in the installation the error Connection Lost in the frontend, that the container restarts continuously and in the log appears the following error:
Oct 17 16:11:24 Loading configuration overwrites from:
Oct 17 16:11:24 - /app/data/configs/default.json
Oct 17 16:11:24
Oct 17 16:11:26 => Started
Oct 17 16:11:26
Oct 17 16:11:26 Editor is now accessible via:
Oct 17 16:11:26 http://localhost:5678/
Oct 17 16:11:26
Oct 17 16:11:26 Manual executions will be visible only for the owner
Oct 17 16:11:26
Oct 17 16:11:26 Press "o" to open in Browser.
Oct 17 16:11:34 /app/code/node_modules/utf8/utf8.js:131
Oct 17 16:11:34 throw Error('Invalid continuation byte');
Oct 17 16:11:34 ^
Oct 17 16:11:34
Oct 17 16:11:34 Error: Invalid continuation byte
Oct 17 16:11:34 at readContinuationByte (/app/code/node_modules/utf8/utf8.js:131:9)
Oct 17 16:11:34 at decodeSymbol (/app/code/node_modules/utf8/utf8.js:184:12)
Oct 17 16:11:34 at Object.utf8decode [as decode] (/app/code/node_modules/utf8/utf8.js:206:17)
Oct 17 16:11:34 at /app/code/node_modules/imap-simple/lib/imapSimple.js:222:50
Oct 17 16:11:34 at processTicksAndRejections (node:internal/process/task_queues:96:5)
Oct 17 16:11:35 => Ensure directories
Oct 17 16:11:35 => Loading configuration
Oct 17 16:11:35 => Setting permissions
Oct 17 16:11:35 => Starting N8N
Oct 17 16:11:36
Oct 17 16:11:36 Loading configuration overwrites from:
Oct 17 16:11:36 - /app/data/configs/default.json
This happens when the workflow containing that node is active. When the workflow is deactivated or the node is not active within the workflow, the application works normally.
We are facing the exact same issue as well, and it’s effecting some of our customers.
Can you please let us know if we have any update on the fix of this issue ? or is there any work around to get the node working ?
Also, if it helps, during our testing, we noticed below error while facing this issue:
(node:36) UnhandledPromiseRejectionWarning: Error: Got 0 parts, should get 1
at /data/packages/nodes-base/node_modules/imap-simple/lib/imapSimple.js:206:28
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
Hope it helps in debugging.
Really Looking forward to hear back on this, thanks.
Hey @Shahtaj_Khalid,
Can you try upgrading to the latest release? We put a fix out that should solve most of the issues now.
Updated 1 day after release and since then i did not have any issues. I set the authentication interval to 5 mins.
To clarify: The issues appeard mostly when the mailserver whent down for maintenance, so the server closed the connection. Because of the “bug” reconnecting did not work as supposed.
For me this can be considered as solved with the changes you made
@Jon That’s great, can you please point towards the exact release it’s fixed in ? we’re not completely in sync with n8n’s releases that’s why need to know about the release so we can sync our node with that release.
Thanks.
@Jon Can you please help me understand what changes have we made to fix this issue ? I was trying to compare the changes between release 0.199.0 (n8n/EmailReadImap.node.ts at [email protected] · n8n-io/n8n · GitHub) with the recent changes from release 0.200.0 (V1) (Comparing [email protected]@0.200.0 · n8n-io/n8n · GitHub)
And I couldn’t find any difference ? We implemented the connection related changes from 0.199.0 and after it we still faced the issue. Now I’m unable to identify the difference among these releases, if you can point it out, it’ll really help.
Thanks.
Hey @Shahtaj_Khalid,
I take it you are not using our shipped node and your own version of it then?
The commit for the changes is this one: fix(Email Trigger (IMAP) Node): improve connection handling and crede… · n8n-io/[email protected] · GitHub