IMAP Email Not Triggering with Gmail

Describe the issue/error/question

IMAP Email does not reliably trigger with Gmail on an active workflow, but works fine when executed at the node or using the Execute Workflow button.

In case it matters, my Gmail email account is under the legacy edition of G Suite and is using an app password as follows.

snip

Please share the workflow

Information on your n8n setup

  • n8n version: 0.182.0
  • Database you’re using (default: SQLite): SQLite
  • Running n8n via [Docker, npm, n8n.cloud, desktop app]: Docker

Hi @MortgageRockstar, I am very sorry to you hear you’re having trouble.

I managed to reproduce this using Gmail and shall add this to our internal bug tracker for a closer look.

Hi @MortgageRockstar, we looked into this in a bit more detail now and it turns out I was overlooking the Ignore SSL Issues setting at first :see_no_evil:

image

Once updated, we were able to reproduce the problem you have described, emails being marked as read but the workflow not running. However, this only occurred when multiple IMAP nodes were active and checking the same inbox. The first one to notice the message would mark the message as read and the other nodes would no longer find them.

So could you double-check that absolutely no other email client or workflow is receiving emails for this inbox? Would you have the same effect when using ALL instead of UNSEEN in your Custom Email Rules field?

I currently have 2 active IMAP nodes in separate workflows using the same Gmail email account, @MutedJam , but each uses different custom email rules. Each has an action to “mark as read”.

I would not expect the email to be marked as read unless it matched the custom email rule, but it sounds as if this may not be the case?

Below is the subject of the email and the custom email rules for the 2 active IMAP nodes in separate workflows.

Subject : New missed call from (555) 555-5555.

Workflow 1 : [“UNSEEN”,[“SUBJECT”,“Application Started”]]
Workflow 2 : [“UNSEEN”,[“FROM","[email protected]”],[“SUBJECT”,“New missed call”]]

Based on the above, I would expect Workflow 2 to be triggered and the email marked as read by Workflow 2 only.

As an aside which I would not expect to have any bearing, Workflow 2 monitors MailBox Name “INBOX” whereas Workflow 1 monitors Mailbox Name “[Gmail Label Name]”.

I did not test using ALL instead of UNSEEN because I would expect that it would trigger all emails, not just those that are unseen (aka unread), right?

So I think it’s still worth a shot testing ALL in a separate trigger node, just to verify if this is indeed two workflows interfering with each other.

However, seeing you are using Gmail I’d avoid using the IMAP trigger node completely and instead go for a polling approach using the designated Gmail node. That way it shouldn’t matter if any other email client or workflow is currently active. You can query unread emails by label, including the UNREAD label to fetch new messages:

image

After processing, you can then update the respective labels to ensure these messages aren’t fetched again:

image

Thanks for the suggestions, @MutedJam.

I think I am going to abandon using IMAP with Gmail to trigger workflows. I need real time triggering rather than polling (plus I believe Google restricts frequent polling).

Do you know if this same behavior will occur if I use a singular non-Gmail email address or is this issue specific to Gmail?

I’d prefer to use one email address, but I can set-up individual email addresses to trigger each workflow if needed.

The rate limit is quite generous: Usage limits  |  Gmail API  |  Google Developers

Plus, the IMAP connection also had a few seconds delay when testing this. So with frequent enough polling you should get similar or better latency with the regular Gmail node over the IMAP node.

Thanks @MutedJam.

I just noticed that I am now getting an error message stating that one of my workflows with the IMAP Email trigger node is active, but could not be started.

I actually noticed this same error for both workflows a couple of days ago.