أواجه مشكلة حيث يتم إيقاف سير عمل يحتوي على عقدة Email Trigger (IMAP) تلقائياً عند محاولة تفعيله، مما يؤدي إلى رمي WorkflowActivationError الذي يتم اكتشافه بواسطة Error Trigger الخاص بسير العمل.
ومع ذلك، التنفيذ اليدوي يعمل بشكل مثالي بدون أي أخطاء.
تفاصيل الخطأ (المكتشفة بواسطة Error Trigger):
[
{
"trigger": {
"error": {
"message": "There was a problem with the trigger node \"Email Trigger (IMAP)\", for that reason did the workflow had to be deactivated",
"timestamp": 1785767782822,
"name": "WorkflowActivationError",
"context": {}
},
"mode": "trigger"
},
"workflow": {
"id": "zTAdqKiYBPODh3yr",
"name": "03.03. Яндекс -> amoCRM (deleted@pioneercert.ru)"
}
}
]
مرحبا @Sokol
WorkflowActivationError هو الغلاف الذي يسلمه n8n إلى مشغل الخطأ عندما يفشل عقدة المشغل، وأخطاء عقدة المشغل تصل دائماً مع context: {} وبدون سبب، لذلك فشل IMAP الفعلي لا يصل إلى واجهة المستخدم ويذهب إلى سجل المثيل بدلاً من ذلك. التشغيل اليدوي يقوم بجلب واحد وإغلاق، والتنشيط يحافظ على الاتصال مفتوحاً، وهذا هو السبب في أن التنشيط فقط هو الذي يؤدي للخطأ. قم بتشغيل سير العمل واقرأ السجل مباشرة بعد:
السطر الذي يبدأ بـ “Email Read Imap:” يحمل السبب الفعلي، عادة ما يكون اتصالاً أُغلق بشكل غير متوقع، أو رفض مصادقة من الخادم، أو خطأ في صندوق البريد، وهذا يحدد الحل. على السحابة، تلك السجلات ليست متاحة من جانبك، help@n8n.io يمكنهم سحب السجلات لسير العمل zTAdqKiYBPODh3yr.
التفصيل المفقود في حمولة الخطأ يتم تتبعه هنا:
مرحبا،
لا تزال على الإصدار 2.33.3، نفس نمط ECONNRESET/EPIPE كما هو الحال قبل الترقية، لا توجد تغييرات.
لاحظت شيئًا واحدًا، أنه لا يقتصر على صندوق بريد واحد، mail@ و deleted@ و notification@ على نفس خادم VPS ينقطعان في نفس الوقت، في نفس حلقة النظام الضيقة. هذا جعلني أتساءل عما إذا كان هذا حقًا شيء على طبقة الشبكة، وليس شيء تفعله Yandex أو n8n لكل حساب. مثل جدار حماية VPS أو جدول conntrack الذي يقتل الاتصالات الخاملة قبل أن يتاح لـ n8n فرصة إعادة الاتصال.
لم أتحقق من انتهاء الصلاحية conntrack حتى الآن، سأقوم بتشغيل
sysctl net.netfilter.nf-conntrack-tcp-timeout-established وسأنشر القيمة. كما سأتحقق من إعدادات Force Reconnect الحالية على هذه العقد حيث لست متأكدًا من أنها مكونة بالفعل.
لماذا لا يتطابق إعداد 15 دقيقة مع ما رأيته في السجل؟
أقدّر مشاركتك لهذا. هناك عنصر واحد يبرز: على الرغم من ضبط Force Reconnect على 15 دقيقة، كانت مشاكل ECONNRESET/EPIPE تحدث بشكل متتالي في حلقة ضيقة بدلاً من حدوثها تقريباً كل 15 دقيقة، وفقاً للسجل الذي قدمته سابقاً. كان يجب أن تتوقع حدوث أعطال موزعة حول 15 دقيقة بعضها عن بعض بدلاً من حدوث طفرة مفاجئة إذا كان Force Reconnect هو المسبب. لذلك، هذا الخيار على الأرجح ليس السبب الرئيسي؛ يتم إنهاء الاتصال قبل انقضاء 15 دقيقة المخصصة بكثير.
من الجدير التحقق مما إذا كانت قيم صناديق البريد الأخرى (mail@، notification@) متطابقة أم أن أحدها مضبوت بشكل مختلف أو غير محدد. هذا سيجعل من الأسهل تحديد ما إذا كانت مسألة تكوين لكل عقدة أو شيء يؤثر عليها جميعاً بالتساوي.
لا تزال أخطط للتحقق من timeout conntrack، سأنشر تلك القيمة بمجرد حصولي عليها — هذا هو الجزء الذي سيخبرنا فعلاً ما إذا كان هذا يتعلق بـ VPS/firewall أو شيء في معالجة n8n’s reconnect.
قم بتشغيل docker logs n8n-n8n-worker-1 2>&1 | grep -i imap وشاهد النتائج. قدم لي النتائج.
أيضاً ما هي قيمة EXECUTIONS_MODE المعيّنة (أو ما إذا كنت تستخدم N8N_DISABLE_PRODUCTION_MAIN_PROCESS).
قدم أيضاً مخرجات سجل العامل من حول نفس النافذة الزمنية كأحد الأعطال في لقطة docker ps/log الخاصة بك، بحيث يمكن بالفعل مواءمة الطوابع الزمنية مقابل أعطال العملية الرئيسية.
ما إذا كان خطأ LOGIN يظهر بشكل متكرر عبر صناديق البريد المختلفة، وما إذا كانت الطوابع الزمنية متجمعة قريبة من بعضها البعض لأنه إذا كانت صناديق بريد متعددة على نفس النطاق/IP تعيد محاولة LOGIN في نفس اللحظات تقريباً، فهذا يبدو وكأنه نظام مكافحة الإساءة/تحديد معدل Yandex يبدأ العمل من محاولات تسجيل الدخول المتكررة التي تصل إليهم من عنوان IP واحد على VPS، وليس مشكلة لكل حساب.
اقتراحي:
رمز sc= هذا معرف تتبع/دعم من جانب Yandex، يستحق أن تأخذه مباشرة إلى دعم Yandex، لأنه إذا كان هذا تحديد معدل، فلا يمكن إصلاحه بحتة من جانب تكوين n8n.
@Sokol المكالمة التي تفشل هي LOGIN وليس socket. “LOGIN internal server error sc=…_imap-production-main-623” هو Yandex يرفض الجلسة، وأزواج ECONNRESET و EPIPE هي تلك الجلسات التي يتم إسقاطها مباشرة بعد ذلك. لا توجد تغييرات إعدادات n8n تغير ذلك، الحل على جانب صندوق البريد.
لكل من deleted@ و mail@ و notification@:
قم بتسجيل الدخول إلى صندوق البريد هذا مرة واحدة على mail.yandex.com. يتم قبول اتفاقية المستخدم عند أول تسجيل دخول عبر الويب، لكل صندوق بريد، وصناديق البريد الخدمية عادة لم تقم بذلك أبداً.
في الإعدادات > عملاء البريد الإلكتروني، تأكد من تفعيل “من خادم imap.yandex.com عبر IMAP” وتعيين طريقة المصادقة على كلمات المرور للتطبيقات.
أنشئ كلمة مرور تطبيق لصندوق البريد هذا في Yandex ID واستخدمها في بيانات اعتماد IMAP في n8n بدلاً من كلمة مرور الحساب.
يقوم Yandex أيضاً بحظر صناديق البريد التي تضع علامة عليها نظام الأمان الخاص به على أنها مريبة، عادة ما تكون تلك التي لا تحتوي على اسم حقيقي أو هاتف مرتبط، وهذا الحظر ينفك بنفسه بعد ساعة أو ساعتين، وهذا يتطابق مع الأخطاء التي تأتي وتذهب بينما التشغيلات اليدوية لا تزال تعمل. Troubleshooting email client issues | Yandex Mail
