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.
هذه هي المشكلة بالضبط؛ لم تكن هناك أخطاء في التنفيذات، وتم إكمال كل تنفيذ بنجاح. لم يتم إضافة البريد الإلكتروني إلى جدول البيانات مراراً وتكراراً. تمت إضافته مرة واحدة فقط، وانتهى الأمر
إذاً إذا لم تكن هناك أخطاء والجدول يحتوي على إدخال واحد فقط، فالمشكلة على الأرجح تكون في أن رد شريكك يضع البريد الإلكتروني في Gmail كرسالة غير مقروءة مرة أخرى. وبسبب ذلك يسحب المشغّل الرسالة كل ساعة من جديد. كحل، أضف مرشحاً مباشرة بعد المشغّل يتحقق مما إذا كان البريد الإلكتروني قد وصل في آخر ساعتين. بهذه الطريقة لن تتمكن رسائل البريد القديمة من الدخول في الحلقة مرة أخرى.
في الواقع، شريكنا لا يرد، بل نحن من نرد على رسائل البريد الإلكتروني. نحن نرد على المستقبل فقط، ونترك شريكنا خارج الموضوع على أي حال. لهذا السبب يبدو الأمر غريباً جداً
حسناً، بالنظر إلى لقطات سير العمل — محفز Gmail (غير مقروء + المرسل من الشريك + الموضوع)، وضع علامة كمقروء باستخدام $('Edit Fields').item.json.id، الرد باستخدام $('Gmail Trigger').item.json.threadId. كل هذا يبدو صحيحاً.
إذا كانت 50 عملية تنفيذ منفصلة كل ساعة تحتفظ بإيجاد نفس الرسالة غير مقروءة وكان “وضع علامة كمقروء” يستمر في الإبلاغ عن النجاح، فهناك شيء ما يعيد الرسالة إلى حالة غير مقروءة بين الاستطلاعات — قد تكون قاعدة مرشح Gmail أو تطبيق الهاتف المحمول أو عميل IMAP آخر يلمس علبة الوارد. لن تتمكن من إصلاح هذا السبب الجذري من داخل n8n. ما يمكنك إصلاحه هو جعل سير العمل يرفض إرسال نفس الرد مرتين بغض النظر عن حالة القراءة.
أضف عقدة Code هذه بين محفز Gmail وEdit Fields. يحافظ على معرّفات الرسائل المعالجة في بيانات سير عمل n8n الثابتة بحيث يتم تصفية التكرارات عبر عمليات التنفيذ:
$getWorkflowStaticData('global') ينجو عبر عمليات التنفيذ على n8n Cloud بحيث تستمر قائمة المعرّفات. في المرة الأولى التي تأتي فيها رسالة، يتم تسجيلها وتمريرها إلى المرحلة التالية؛ في المرة الثانية، يسقطها المرشح ويقصر سير العمل إلى صفر عناصر. الآن حتى لو احتفظت Gmail بإعادة وضع علامة غير مقروءة، فأنت ترسل الرد مرة واحدة بالضبط لكل معرّف رسالة فريد.
