خط أنابيبي يتكون من عدة محفزات webhook وعدة محفزات جدولة، بالإضافة إلى حوالي 15 سير عمل فرعي متداخل (يتم استدعاؤها من خلال Execute Workflow).
مؤخراً أردت إعداد بيئة تطوير. لا يمكنني توجيه webhooks الخاصة بي إلى هدف تطوير منفصل، لذا كانت أفضل فكرة توصلت إليها هي نسخ خط الأنابيب بالكامل وربط النسخة بالخط الرئيسي من خلال عقدة IF ومتغير عام dev: on/off. عندما يكون dev مفعلاً، يتم تكرار كل حمولة واردة وأيضاً يتم دفعها إلى نسخة التطوير من خلال webhook. عندما يكون dev معطلاً، يعمل الإنتاج فقط. الهدف كان اختبار نفس البيانات الفعلية التي تصل إلى الإنتاج، لكن على نسخة التطوير، وبمجرد أن ينجح شيء ما هناك، نقله إلى الإنتاج. هذا مهم لأنني، كما قلت، لدي حوالي 15 سير عمل فرعي متداخل، لذا أريد فعلاً التحقق من التغييرات على حركة المرور الفعلية قبل تعزيزها.
بعد أن وصلت نسخة التطوير إلى الإنتاج، بدأت أواجه مشاكل غريبة لم أواجهها من قبل:
بعض أسر العمل الفرعية التي كانت واضحة أنها منشورة في سير العمل الرئيسي بدأت تطرح أخطاء مثل “سير عمل فرعي غير منشور”. هذا لم يكن منطقياً بالنسبة لي، فهي كانت منشورة.
بدأت أواجه مشاكل تنافس على الموارد في كل عقدة تقريباً تتعامل مع جداول بيانات n8n / قاعدة البيانات المدمجة.
حذف خط أنابيب التطوير أزال كل هذا فوراً.
لذا لدي سؤالان:
إذا بدأ n8n بالتصرف بهذه الطريقة (أخطاء “سير عمل فرعي غير منشور” خاطئة ومشاكل تنافس على الموارد) فقط من مضاعفة عدد أسر العمل الفرعية والتنفيذات تقريباً، هل يجب أن أقلق بأن مجرد نمو الإنتاج العادي الخاص بي مع المزيد من أسر العمل الفرعية المتداخلة بمرور الوقت قد يؤدي إلى نفس الأخطاء؟ هل هناك حد معروف أو مشكلة معروفة حول عدد أسر العمل الفرعية المتداخلة أو التنفيذات المتزامنة على خطة Pro؟
ما هي الطريقة الموصى بها لبناء بيئة تطوير في حالتي؟ لا يمكنني إعادة توجيه webhooks بسهولة، لدي عدة أسر عمل فرعية متداخلة، وأريد الاختبار على نفس البيانات الفعلية التي يتلقاها الإنتاج.
ما رسالة الخطأ (إن وجدت)؟
“سير عمل فرعي غير منشور” على أسر عمل فرعية منشورة فعلاً، بالإضافة إلى أخطاء تنافس على الموارد متقطعة على العقد التي تستخدم جداول بيانات n8n.
شارك الإخراج المُرجع من آخر عقدة
(استدعاء سير العمل الفرعي الفاشل يُرجع خطأ "سير عمل فرعي غير منشور" بدلاً من التنفيذ)
معلومات عن إعداد n8n الخاص بك
إصدار n8n: 2.25.7
قاعدة البيانات (الافتراضي: SQLite): n8n افتراضي
إعداد EXECUTIONS_PROCESS لـ n8n (الافتراضي: own, main): الافتراضي (مُدار من قِبل n8n Cloud)
تشغيل n8n عبر (Docker, npm, n8n cloud, desktop app): n8n Cloud
بما أنك تملك أكثر من 15 سير عمل متداخل وتواجه مشاكل تزامن، فقد تجاوزت طاقة نهج “النسخة الواحدة” للتطوير.
المعيار الذهبي لـ n8n هو أن تملك نسخة n8n منفصلة تماماً للتطوير. بما أنك لا تستطيع تغيير مصدر webhook، استخدم نسخة الإنتاج كـ “وسيط بسيط.”
نسخة الإنتاج: تستقبل webhook → ترسل فوراً HTTP Request إلى عنوان webhook نسخة التطوير → تستمر مع منطق الإنتاج.
نسخة التطوير: حساب/نسخة n8n Cloud منفصلة تماماً.
لماذا يعمل هذا: نسخة التطوير لها قاعدة بيانات خاصة بها. لا يوجد أي تنافس على الموارد. إذا توقفت نسخة التطوير أو تعطلت، لن يكون لها أي تأثير على تنفيذ الإنتاج.
كان لديّ خط أنابيب التطوير تماماً كما تذكر: في كل محفز كان لديّ عقدة if/else تتحقق من متغير عام (dev: on/off) ثم عقدة HTTP POST تُرسل (تمرر) البيانات إلى dev. مع فهم أن هذا المنطق لا ينبغي أن يحمّل الموارد بشكل محتمل، واجهت سلوكاً غير متوقع من جانب n8n. ربما يكون لدى n8n حدود موارد عند استضافتها من خلال السحابة؟
لا توجد حدود قاسية موثقة على سير العمل الفرعي. المشكلة التي واجهتها ليست تتعلق بالعدد، بل بـ SQLite والتزامن. تستخدم نسختك على Cloud قاعدة بيانات SQLite افتراضياً، و SQLite لديها قفل كاتب واحد. عندما ضاعفت خط الأنابيب، كانت نسخ الإنتاج والتطوير تكتب إلى نفس Data Tables في نفس الوقت، مما تسبب في تنازع الكتابة. أخطاء “sub-workflow غير منشورة” هي على الأرجح نتيجة جانبية لهذا التنازع: عندما لا يستطيع n8n حل مرجع sub-workflow بسرعة كافية تحت ضغط الموارد، قد يرمي أخطاء مضللة. لذا فإن نمو الإنتاج الطبيعي بمرور الوقت لن يسبب نفس المشكلة ما لم تكن تضاعف أيضاً الكتابات المتزامنة إلى Data Tables.
بالنسبة لبيئة التطوير على Cloud، يعمل نهج kjooleng للنسخة المنفصلة. بديل أرخص يبقى ضمن نسخة واحدة: بدلاً من تكرار خط الأنابيب بالكامل، استخدم إصدار سير العمل في n8n. قم بإجراء تغييرات في سير العمل، احفظ دون نشر، ثم اختبر يدويًا. تستخدم عمليات الإنتاج دائماً النسخة المنشورة حالياً، لذا يستمر الإنتاج في تشغيل آخر نسخة منشورة بينما تختبر التغييرات على المسودة المحفوظة. بمجرد التحقق، انشر. هذا لا يغطي الاختبار مع حركة webhook المباشرة، لكنه يتجنب مشكلة التكرار تماماً.
للاختبار باستخدام حركة مباشرة بشكل محدد، نهج kjooleng في توجيه البروكسي إلى نسخة منفصلة هو الخيار الصحيح.
@pohgen أخبار سارة: لا يوجد حد أقصى صارم للمسارات الفرعية المتداخلة، ولن ينشئ النمو في الإنتاج هذا. على Cloud، التزامن (Pro = 50) يعتمد فقط على تنفيذات webhook/trigger، وليس على استدعاءات Execute Workflow، لذا المسارات الفرعية المتداخلة الأكثر لا تستنزف ميزانيتك.
ما تسبب في المشكلة كان استنساخ المسار إلى نفس المثيل: أخطاء “المسار الفرعي غير المنشور” هي نسخ الإنتاج والتطوير التي تصطدم ببعضها (المسارات الفرعية المكررة تدع Execute Workflow يصل إلى النسخة الخاطئة/غير المنشورة)، سباقات Data Table هي كلا النسختين تهاجمان نفس الجداول المدمجة في نفس الوقت، وأنت ضاعفت تنفيذات webhook التي تحتسب بفعل الحد الأقصى 50. حذف النسخة الإنمائية الذي أصلح كل شيء يؤكد أنها الازدواجية، وليس العدد.
للتطوير: استخدم مثيل n8n منفصل مع Data Tables خاصة به حتى لا يمكنه التنافس مع الإنتاج. لاختبار البيانات الحقيقية دون إعادة توجيه webhooks، التقط حمولات الإنتاج وأعد تشغيلها في التطوير بدلاً من المشاركة المباشرة للحركة.