لدينا مشكلة في webhooks عبر عدة سير عمل. هناك حالات متعددة، دائماً حول الساعة 12 صباحاً/ظهراً ~ 12:20 صباحاً/ظهراً، حيث لا يمكن استدعاء بعض webhooks ويرمي n8n “There was a problem executing the workflow”. أو أن الخادم الخلفي يعمل بمهلة زمنية محددة، لا يتم تسجيل أي تنفيذ (حتى وإن كان تسجيل التنفيذات مفعلاً). لا توجد رسالة خطأ أخرى، فقط هذه الرسالة العامة. هل هناك مكان يمكنني فيه معرفة المزيد من المعلومات حول هذا الخطأ على مثيل n8n الخاص بي؟
المكان الوحيد للعثور على الخطأ “الفعلي” هو في سجلات خدمة Render.com.
ما يجب البحث عنه: انتقل إلى لوحة التحكم Render الخاصة بك →→ خدمة n8n الخاصة بك →→ السجلات.
كلمات رئيسية محددة: ابحث عن SQLITE_BUSY أو database is locked أو Out of Memory أو Killed أو Segmentation fault حول الطوابع الزمنية 12:00 AM/PM.
نصيحة احترافية: للحصول على مزيد من التفاصيل، أضف متغير البيئة N8N_LOG_LEVEL=debug إلى إعدادات Render الخاصة بك وأعد التشغيل. سيؤدي هذا إلى إجبار n8n على طباعة مزيد من الأحداث الداخلية المفصلة في سجلات Render.
بناءً على وصفك، هذا السلوك عادة ما يكون سببه أحد أمرين: قفل قاعدة البيانات أو استنزاف الذاكرة (OOM).
هذا هو الإصلاح الموصى به:
الترحيل إلى PostgreSQL: SQLite غير مصمم للتزامن في الإنتاج. يوفر Render قاعدة بيانات PostgreSQL مُدارة. الترحيل إلى Postgres يزيل مشكلة “قفل الكتابة” بالكامل وهي التوصية القياسية لأي instance من n8n يتعامل مع webhooks الإنتاج. سيحل مشاكل انقطاعات الساعة 12:00 وأخطاء “مشكلة في التنفيذ” العامة بشكل دائم.
@Florian_Glappa كنت أتوقع أن يؤدي هذا الخطأ إلى تفعيل شيء ما في سجلات n8n. هل من الممكن أن يأخذ Render نسخة احتياطية / لقطة شاملة في حوالي منتصف الليل؟ نافذة مدتها 20 دقيقة حول نفس الوقت تشير إلى شيء بيئي بدلاً من خطأ على جانب التطبيق.
إضافة إلى الزاوية البيئية لـ Jon — هناك أيضًا نمط من جانب التطبيق يتطابق تمامًا مع أعراضك ولم يتم ذكره حتى الآن: 0 0,12 * * * هو أحد أكثر تعبيرات cron شيوعًا في الوجود. إذا كان لأي سير عمل على مثيلك (ليس فقط السير المتعطلة) محفز جدول يتم تشغيله في 00:00 و 12:00، فإن مهمة ثقيلة مرتين يوميًا يمكن أن تشبع المثيل بشكل مختصر، و webhooks الواردة هي ما يفشل بشكل مرئي. يستحق إجراء جرد سريع لكل Schedule Trigger عبر جميع سير العمل، ثم تحقق من قائمة التنفيذات المرشحة لتلك النوافذ: هل يوجد تشغيل مجدول دائمًا في الرحلة عندما تتعطل webhooks؟
الشيء الثاني الذي يتطابق مع “لا توجد بيانات تنفيذ مسجلة على الرغم من تفعيل الحفظ”: استنزاف تجمع اتصال Postgres. تجمع n8n الافتراضي لكل عملية رئيسية صغير، وعندما تبدأ عدة تنفيذات في نفس اللحظة، يجف التجمع — يمكن بعد ذلك فشل التنفيذات الجديدة قبل أن يتمكن n8n من كتابة أي شيء إلى جدول التنفيذات، والخطأ يعود إلى المتصل بـ webhook دون الكثير من الهبوط في سجلات الخدمة. هذا سيفسر سبب عدم ظهور أي شيء تقريبًا في سجلات Render. فحصان: رفع DB_POSTGRESDB_POOL_SIZE (على سبيل المثال إلى 10) وانظر إذا تغير النمط، والبحث في سجلات جانب Postgres (سجلات قاعدة بيانات Render، وليس سجلات خدمة n8n) عن أخطاء الاتصال أو ارتفاعات الكمون في تلك النوافذ — سيؤدي نسخ احتياطي من قاعدة البيانات المُدارة أيضًا إلى ظهوره هناك، مما سيؤكد نظرية Jon دون تخمين.
ولأنه يمكن التنبؤ به كثيرًا: راقبه مباشرة مرة واحدة. docker logs -f (مع تفعيل debug، كما اقترح kjooleng) من 11:55 إلى 12:25 سيخبرك أكثر من يوم من التمرير، بالإضافة إلى تصفية قائمة التنفيذات حسب الحالة “crashed” — هذه لا تظهر دائمًا حيث تتوقعها.
إذا أسفر جرد cron عن مهمة مرتين يوميًا، الإصلاح المعتاد هو نقلها إلى وقت فردي (نمط 03:17) ودمجها. تجميع الجداول الزمنية في دقائق فردية هي عادة جيدة على أي n8n بمثيل واحد على أي حال.
مرحبا، كانت هذه نصيحة جيدة حقا، شكرا لك! وجدت مهمة cron تبدأ في 00:05 و 12:05 وعادة ما تستغرق 15 دقيقة واستهلكت كمية سخيفة من الذاكرة. أعدت بناء هذا الآن، أعتقد أن هذا كان هو السبب. شكرا جزيلا!
