Had an issue with a Gmail autoreply workflow, it started sending a reply to a same address over an over again, even after deactivating all nodes (which is really weird).
How it works:
Our email get cc’d by our partner on emails sent to leads. First node gets triggered once an hour to find emails from our partner’s email address, with filtering by the subject line AND by only unread emails. Then it sets variables for the recipient’s email address and the message id. Next node marks the message as read by using the id. Then, the next node replies in the thread using thread id from the trigger. Then add the lead to a table and create a lead in zoho.
It started a week ago, we just noticed it recently. The weirdest part is that it still sent emails even after we deactivated the nodes, so we unpublished the workflow just to be sure.
I saw some similar threads here, but this seems to be a little bit different, we’re filtering out unread messages, but it still pulls up the same email over and over.
@Arsen the “still sending after deactivation” part is queued executions that fired before deactivate kicked in — n8n Cloud doesnt cancel in-flight runs, just stops NEW triggers. so the 50 replies are 50 backlogged executions that were already on the queue.
root cause of the 50 in the first place is probably ordering — if the mark-as-read step fails or runs slowly, the next hourly poll sees the same unread message again and fires another reply. did the mark-as-read step actually succeed in each execution log, or fail silently?
Welcome to the n8n community @Arsen
Please update your instance to v2.21.7 through the admin panel.
Return to the workflow, disable the nodes and enable them again. publish
Run it, and return the result to us if possible.
The actual issue is a race condition between the trigger and the mark-as-read node. Gmail returns unread emails based on the status at the time of the API request. If the trigger fetches the email and the mark-as-read node hasn’t executed yet, the next execution can fetch the same email again, especially if executions overlap.
The best solution is to add a deduplicating filter based on the message ID after the trigger. Store processed message IDs in a Static Data Store or a Google Sheet. Before processing, check whether the ID already exists.
Hi @Arsen
Can you please check the Gmail auto reply settings?
You Go to Gmail > Settings > General > Vacation Responder (Vacation responder off/on).
If auto-reply is turned off. Then, make sure to follow these steps.
Test it in a small scope by duplicating the workflow, just change the settings instead reading from partner email to read from your email (other than the ccd one)
Keep all your settings and use one email (new email that you can send or receive from to test)
reduce the trigger time to 1 mins for testing only,
stop at replying the message (since this is the show stopper)
Make sure to make a step by step flow testing (beforeing publishing)
If it worked well, then publish the small scope
test it again in production, and it should work!
Exactly, if the same email keeps appearing in the spreadsheet, that confirms the issue.
The solution is a code node right after the trigger that checks whether the message ID has already been processed. If you need help with the exact setup, I’m happy to help!
@Arsen in the execution logs, do 49 of those runs show a failure/error on the node immediately after the reply node? If yes, the workflow was completing the reply successfully, then hitting an error downstream, but since n8n had already sent the email, the damage was done.
That’s exactly the issue; there were NO errors in the executions, and every execution was completed successfully. The email wasn’t being added to the spreadsheet over and over again. It was added once, and that’s it
So if there are no errors and the table only has one entry, the problem is likely that your partner’s response is marking the email as unread in Gmail again. This causes the trigger to pull it every hour. As a solution, add a filter right after the trigger that checks whether the email arrived in the last 2 hours. That way, old emails can’t get caught in the loop anymore.
Actually, our partner doesn’t respond, it’s we who is responding to the emails. We’re responding to only the recipient, and leave out our partner anyway. That’s why it’s really weird
Ok then the partner theory is ruled out. My next suspicion is that Gmail internally marks the email as unread again after your reply because the thread is being updated.
As a test, add a short wait time of 1-2 seconds after the “Mark as Read” node, then “Mark as Read” again. Sometimes Gmail needs a moment for the change to take effect.
ok looking at the workflow screenshots — Gmail Trigger filter (unread + partner sender + subject), Mark as Read using $('Edit Fields').item.json.id, Reply using $('Gmail Trigger').item.json.threadId. that all reads fine.
if 50 separate hourly executions all keep finding the SAME message unread AND mark-as-read keeps reporting success, something is flipping the email back to unread between polls — could be a Gmail filter rule, the mobile app, or another IMAP client touching the inbox. ur not gonna fix that root cause from inside n8n. what u CAN fix is making the workflow refuse to send the same reply twice regardless of read state.
drop this Code node between the Gmail Trigger and Edit Fields. it persists processed message IDs in n8n’s static workflow data so dupes get filtered out across executions:
$getWorkflowStaticData('global') survives across executions on n8n Cloud so the ID list persists. first time a message comes through it gets logged + passed downstream; second time the filter drops it and the workflow short-circuits to zero items. now even if Gmail keeps re-marking unread, u send the reply exactly once per unique message ID.
