IMAP Email node is no longer triggering workflow which has worked for 1+ month. IMAP credentials (non-Gmail) show as “connection tested successfully”. Appears to have stopped working sometime between 9/16/22 and 9/20/22 and no new executions showing in log.
What is the error message (if any)?
None. Workflow no longer triggers from IMAP Email node.
Information on your n8n setup
n8n version: 0.193.5
Database you’re using (default: SQLite): SQLite
Running n8n with the execution process [own(default), main]: Own? Not sure what this means.
Running n8n via [Docker, npm, n8n.cloud, desktop app]: Docker
Hi @MortgageRockstar, I am sorry to hear you’re having trouble. Which email provider are you using and which settings do you use in your credentials (host, port, ssl/tls)? I seem to remember that MS wanted to phase out IMAP authentication for MS365 accounts, so am wondering if you might be affected by this.
I guess I spoke too soon. This issue has re-occurred.
As mentioned above, I am using VPS Hosting with KnownHost on port 993 with SSL/TLS.
My credentials for this email address continue to show as “connection tested successfully”, but the workflow does not trigger (no executions showing in log) with incoming email.
What mail provider are you using or do KnownHost also provide that? When it stops working is the workflow still active? If you check the docker log for the n8n container does it show any error messages?
The workflow is active in addition to the credentials.
I do have an Error Trigger node defined in a workflow, but it is not triggered. The workflow simply is not being triggered with the IMAP Email mode despite unread emails in the mailbox.
I’m not sure what docker logs you are referencing. I used the command “docker logs [container name]” and it outputs the workflows that are active, but that’s it.
I previously tried to enable logging through n8n environment variables, but it caused my n8n instance not to load successfully.
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.
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.
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.
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.
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.
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.
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.
