Good day.
Tell me the logic of the imap email node - how does it work?
imap email - processes all emails every time it is launched. How can I make imap email not process the emails that it has already processed?
Example:
there are emails email1, email2, email3.
We launch imap email - it processes email1, email2, email3 and completes the entire chain of processes.
Let’s say something happened (the server froze, was turned off manually, …).
At this time, there are already 10 emails in the mail - email1, email2, email3, email4, … email10.
We launch imap email - and again email1, email2, email3, email4, … email10 will be processed.
How can I make it so that only email4, email5 … email10 are processed?
Thanks for posting here and welcome to the community!
What do you mean by “launching” the IMAP node? How have you configured it? Can you share your workflow?
Tip for sharing your workflow in the forum
Pasting your n8n workflow
Ensure to copy your n8n workflow and paste it in the code block, that is in between the pairs of triple backticks, which also could be achieved by clicking </> (preformatted text) in the editor and pasting in your workflow.
```
<your workflow>
```
Make sure that you’ve removed any sensitive information from your workflow and include dummy data or pinned data as much as you can!
Thanks for sharing your workflow, the picture is much clearer now, what’s going on
Since you’ve set a filter to get all mails after a specific date, that’s what it does every time when the node is tested (manual execution).
That’s because we track the last message’s uid and store it in the workflow’s static data, which however is only stored in production.
So when you run the IMAP node manually (test mode) this is expected behaviour.
Maybe you can iterate on your filter logic and further processing to work around that if you happen to need to run the node manually often ?
Have a look at the node-imap library for other search flags:
It depends on how your n8n server is rebooted. In theory though it should still contain the last message uid’s and therefore “remember” the messages it had already processed.
The default behaviour of the node is to fetch all new unread messages. So if you delete your ["ALL", ["SINCE", "november 10, 2024"]] filter, this should work as expected in production.