مرحبا بالجميع!
أنا أقوم بتشغيل n8n 2.21.7 في وضع الطابور (EXECUTIONS_MODE=queue) مع
PostgreSQL و Redis، مستضاف على Easypanel مع Docker.
قمت ببناء سير عمل باستخدام Form Trigger مع تعيين responseMode إلى
‘lastNode’، متبوعًا بـ AI Agent node (OpenAI)، و Form
completion node لعرض النتيجة على الشاشة.
سير العمل يعمل بشكل مثالي عندما أختبره يدويًا داخل المحرر.
لكن عندما أرسل النموذج في الإنتاج، يفشل على الفور مع هذا الخطأ:
“Cannot read properties of undefined (reading ‘execute’)”
الشيء الغريب هو أن runData فارغ تمامًا عندما يحدث الخطأ — يبدو أنه
يفشل قبل أن تبدأ أي عقدة حتى في التنفيذ.
يشير تتبع المكدس إلى bull@4.16.4 Queue.onFailed.
جميع سير العمل الآخر لدي يعمل بشكل جيد في الإنتاج. تبدو المشكلة خاصة
بـ Form Trigger عندما تحتاج إلى الحفاظ على الاتصال مفتوحًا في انتظار
استجابة العقدة الأخيرة.
حاولت بالفعل تعيين N8N_RUNNERS_ENABLED=false لكن الخطأ يستمر.
هل واجه أحد هذا من قبل؟ أي أفكار حول ما قد يسبب هذا؟
شكرا!
رسالة الخطأ “Cannot read properties of undefined (reading ‘execute’)” تظهر عبر مجموعات أوضاع الطابور المختلفة — "On form submission" trigger not working using the production URL · Issue #19317 · n8n-io/n8n · GitHub يحتوي على نفس المشكلة بخصوص مشغلات النماذج على عناوين URL الإنتاجية، و Postgres Node Fails in Queue Mode: “Cannot read properties of undefined (reading ‘execute’)” · Issue #15154 · n8n-io/n8n · GitHub واجهها مع Postgres في وضع الطابور. تم إغلاق #15154 باعتباره “غير مخطط” بدون إصلاح، لذا فهو خطأ مفتوح في n8n وليس شيئاً على طرفك.
يستحق المحاولة كحل بديل: غيّر “Respond When” في Form Trigger من “Workflow Finishes” إلى “Form Is Submitted”. ستفقد عرض النتيجة المباشرة على صفحة النموذج لكن الرد يعود فوراً عند الإرسال، مما يتجنب أياً كان ما يفعله نقل الطابور بشكل خاطئ. هل جربت ذلك؟
مرحباً @ricardo_balako
الخطأ الذي تواجهه، “Cannot read properties of undefined (reading ‘execute’)”، هو عرض كلاسيكي لانهيار الاتصال في وضع الطابور في n8n. لأن سير العمل الخاص بك يعمل بشكل صحيح داخل المحرر لكنه يفشل في الإنتاج، فالمشكلة بكل تأكيد لا تتعلق بمنطق سير العمل نفسه، بل بكيفية تعامل بيئتك الموزعة مع المهمة. في وضع الطابور، ترسل النسخة الأساسية مهمة إلى عملية عامل منفصلة، وإذا كان هذا العامل غير قادر على تهيئة العقدة المطلوبة بشكل صحيح، فسيتعطل قبل أن يتمكن حتى من بدء التنفيذ.
السبب الأكثر شيوعاً لهذا هو عدم تطابق الإصدار بين نسختك الأساسية ونسخة العامل. حتى لو بدا أن كلاهما يعمل بأحدث إصدار، فإن الاختلافات الطفيفة في صور Docker الأساسية يمكن أن تمنعهما من التواصل بشكل صحيح. من الضروري التأكد من أن كلا الخدمتين تستخدمان نفس العلامة الصورة بالضبط وأن تقوم بإعادة نشر كامل لكلا المكونين في نفس الوقت لضمان مزامنتهما.
عامل حاسم آخر هو اتساق متغيرات البيئة عبر بنيتك التحتية. يجب أن تشترك خدمات العامل والأساسية في نفس الإعدادات بالضبط، خاصة فيما يتعلق بمفتاح التشفير وتفاصيل اتصال قاعدة البيانات وإعدادات Redis. إذا كان العامل يفتقد الإعدادات الصحيحة، فقد يفشل في المصادقة مع قاعدة البيانات أو Redis، مما يسبب خطأ “undefined” عندما يحاول استرجاع بيانات سير العمل التي يحتاجها لبدء المهمة.
يجب عليك أيضاً التحقق من أن خدمة العامل الخاصة بك مكونة للعمل على وجه التحديد كعملية عامل. في إعداد Easypanel الخاص بك، تأكد من أن الأمر الخاص بحاوية العامل معين على worker (على سبيل المثال، n8n worker). بالإضافة إلى ذلك، تعيين متغير البيئة N8N_REINSTALL_MISSING_PACKAGES=true على العامل الخاص بك هي ممارسة جيدة، لأنها تضمن أن العامل لديه جميع التبعيات الضرورية، مثل تلك المطلوبة من قبل عقدة AI Agent، والتي قد تكون مفقودة في بيئة عامل جديدة.
حقيقة أن الخطأ يشير إلى bull (مكتبة إدارة الطابور) تؤكد أن الفشل يحدث على مستوى البنية التحتية. أفضل طريقة للوصول إلى جذر المشكلة هي تجاهل سجلات n8n الرئيسية والتركيز حصرياً على سجلات حاوية العامل في اللحظة بالضبط التي تقدم فيها النموذج. ستوفر هذه السجلات الخاصة بالعامل غالباً السبب المحدد—مثل انتهاء صلاحية الاتصال أو تبعية مفقودة—أن المهمة فشلت في التهيئة.
إذا تحققت من الإصدار والإعدادات والسجلات واستمرت المشكلة، فقد تريد الاختبار بتعيين EXECUTIONS_PROCESS=main على نسختك الأساسية كخطوة تشخيصية مؤقتة. بينما يتجاوز هذا بنية العامل، فإنه سيؤكد ما إذا كانت المشكلة مرتبطة بشكل صارم بنظام الطابور. إذا عمل سير العمل بشكل جيد في هذا الوضع، فهذا يؤكد أن مشكلتك معزولة على التفاعل بين نسخة n8n الأساسية وعمليات العامل.
مرحباً @ricardo_balako!
السبب الجذري هنا معماري: Form Trigger مع responseMode=lastNode يتطلب من عملية n8n الرئيسية الاحتفاظ بالاتصال HTTP مفتوحاً حتى ينتهي سير العمل. في وضع الطابور، يتم تسليم التنفيذ إلى عامل - وهذا الاتصال المفتوح لا يمكنه متابعته عبر حدود العملية. Queue.onFailed في تتبع المكدس الخاص بك يؤكد أن المهمة تتوقف على مستوى الطابور قبل أن تبدأ أي عقدة حتى.
الإصلاح الأسرع هو ما اقترحه achamm - بدّل “Respond When” إلى “Form Is Submitted.” إذا كنت بحاجة إلى عرض نتيجة الذكاء الاصطناعي للمستخدم، فإن النمط الشائع هو إعادة توجيههم إلى صفحة نتيجة تستطلع webhook أو تتحقق من نقطة نهاية الحالة.
إذا كنت حقاً بحاجة إلى وضع lastNode، فإن الخيار النظيف الوحيد هو تشغيل تلك سير العمل المحددة خارج وضع الطابور - إما باستخدام EXECUTIONS_PROCESS=main على نفس المثيل (غير موصى به عند التوسع) أو على مثيل n8n منفصل بدون تفعيل وضع الطابور.
من المفيد أيضاً إجراء فحص سريع: تأكد من أن حاوية العامل الخاصة بك تعمل بالضبط على الإصدار 2.21.7 وتشارك نفس N8N_ENCRYPTION_KEY - عدم التطابق هناك ينتج عن هذا نمط الفشل بالضبط.
من المفيد التأكيد على ما تم التلميح إليه بالفعل: هذا خلل معروف في n8n يتعلق بمشغلات نمط النموذج/webhook في وضع الطابور، وليس هناك شيء خاطئ في سير العمل الخاص بك. يعمل في المحرر لأن التنفيذ اليدوي يتم في العملية الرئيسية، ويفشل في عنوان URL الإنتاجي لأنه في وضع الطابور تلتقطه عملية عاملة وسياق المشغل لا يتم توصيله بنفس الطريقة.
مسارات عملية حتى يتم إصلاحه من قبل المصدر. إذا كان سير العمل هذا لا يحتاج إلى قابلية التوسع في وضع الطابور، فقم بتشغيله في وضع التنفيذ العادي (الرئيسي) واحتفظ بوضع الطابور لسير العمل الثقيل. إذا كان كل شيء يجب أن يكون في وضع الطابور، فإن الحل البديل الشائع هو تقسيمه: عقدة Webhook عادية تستقبل منشور النموذج (تتصرف webhooks بشكل أفضل من Form Trigger في وضع الطابور)، ثم التعامل مع الاستجابة بشكل منفصل بدلاً من الاعتماد على responseMode lastNode عبر عقدة النموذج.
بما أن مشكلة GitHub ذات الصلة تم إغلاقها كغير مخطط لها، فلا تنتظر إصلاح. اشترك فيها للحصول على الرؤية لكن ابن حولها الآن. أي إصدار n8n بالضبط تستخدم، في حالة وجود نافذة انحدار تستحق الإشارة إليها.
تم حل المشكلة! إليك ما نجح معي:
كانت المشكلة بالضبط ما وصفته @kjooleng — عدم توافق الإصدار بين خدماتي n8n. أنا أقوم بتشغيل n8n على Easypanel مع ثلاث خدمات منفصلة: n8n_start، n8n_webhook و n8n_worker. كانت جميعها تعمل بإصدارات مختلفة من صورة Docker، مما تسبب في توقف اتصالات الطابور قبل حتى تنفيذ أي عقدة.
كان الحل بسيطاً: قمت بتحديث الخدمات الثلاث إلى نفس الوسم latest وأعدت نشرها جميعاً في نفس الوقت. بعد ذلك، عمل كل شيء بشكل مثالي في بيئة الإنتاج.
الخلاصة الرئيسية: إذا كنت تقوم بتشغيل n8n في وضع الطابور مع حاويات منفصلة للعامل والويب هوك، تأكد من أن جميع الخدمات في نفس الإصدار تماماً. حتى فرق صغير بين الحالة الرئيسية والعامل كافٍ لتفعيل هذا الخطأ.
شكراً لجميعكم على المساعدة!