وجدت بعض الإجابات حول الاختبار إذا كان سير العمل قيد التشغيل. لكنني مهتم بمعرفة ما إذا كان منشورًا وموافقًا عليه (مثل النقطة الخضراء بجانبه في عرض محرر سير العمل).
وصف المشكلة/الخطأ/السؤال
تشغيل n8n محليًا على الكمبيوتر المحمول.
السياق: قمت بإنشاء سير عمل يتم تشغيله / ~10 دقائق. يتحقق من رسائلي الإلكترونية، ويختار بعضها ويلخصها، ثم يرسلها إلى قناة RocketChat.
للأسف، تحدث أخطاء كثيرة، مما “ينشرها” (على سبيل المثال: خطأ موفر البريد، أخطاء LLM، إغلاق غطاء الكمبيوتر المحمول → n8n ينام، إلخ).
لذا، قمت بإنشاء سير عمل ثانوي يعيد تشغيل الأول:
عند حدوث أي خطأ (العقد في سير العمل الأساسي تثير أخطاء)
عند بدء تشغيل n8n (حاوية n8n تبدأ عند الإقلاع)
لكن لا تزال أحصل على حالات يتوقف فيها سير العمل الأساسي. أريد أن أضيف حالة ثالثة:
مشغل كل ساعة واحدة يتحقق مما إذا كان سير العمل “معطلاً” وإذا كان الحال كذلك، فأعد تشغيله.
عندما أستخدم عقدة API لاسترجاع سير العمل الأساسي، يمكنني الحصول على “workflowPublishHistory” أو “active”. للأسف، كلاهما صحيح/مُفعّل حتى لو كان سير العمل في حالة خطأ (نقطة حمراء في عرض المحرر).
بسبب إعدادي الخاص:
لا يمكنني ببساطة التحقق من نشر سير العمل الأساسي
لا يمكنني ببساطة التحقق مما إذا كان قيد التشغيل، مثل الرسائل التي وجدتها هنا، لأن سير العمل الخاص بي يمكن أن يكون “نائمًا” بين مشغلين بفارق 10 دقائق.
إذن سؤالي: كيف أحصل على نفس المعلومات التي تكمن وراء عرض النقطة الحمراء/الخضراء/الصفراء بجانب سير العمل في وضع المحرر، باستخدام عقدة n8n API؟
معلومات حول إعداد n8n الخاص بك
إصدار n8n: 2.45.7
قاعدة البيانات (الافتراضي: SQLite): افتراضي
إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main): own, main
تشغيل n8n عبر (Docker, npm, n8n cloud, تطبيق سطح المكتب): التشغيل في حاوية incus مخصصة تبدأ npx n8n
التحقق من العلم active عبر واجهة برمجة تطبيقات n8n يخبرك فقط ما إذا كان سير العمل مفعلاً، وهذا هو السبب في بقاؤه صحيحاً حتى عندما تؤدي أخطاء وقت التشغيل إلى ظهور نقطة حمراء. للتحقق من الصحة برمجياً، يجب عليك الاستعلام عن نقطة النهاية /executions مع تصفيتها بـ status=error جنباً إلى جنب مع فحص حالة سير العمل للتحقق مما إذا كان آخر تشغيل قد نجح. أخبرني بخادم قاعدة البيانات الذي تستخدمه لإعدادك المستضاف ذاتياً وسأتمكن من تحديد تسلسل استدعاء API الدقيق هنا.
مرحباً @liar666 أهلاً وسهلاً في المجتمع،
عقدة n8n API الخاصة بـ Workflow Get لا تعرض نفس الحالة التي تظهرها النقطة في الإصدار 2.45.7. يدمج المحرر حالة نشر المشغّل مع التغييرات الم草ودة ومشاكل الإعدادات، لذا فإن active=true لا يضمن وجود نقطة خضراء.
مع تفعيل خدمة النشر الافتراضية، يستخدم المحرر GET /rest/workflows/<id>/publication-status. الاستجابة الخاصة به تحتوي على data.status (published أو partial أو failed أو in_progress أو not_published) و data.triggers مع أخطاء التفعيل. يمكنك فحصها في متصفحك أثناء تسجيل الدخول. إنها مسار مصرح به بجلسة داخلية، لذا لن يعمل مفتاح n8n API الخاص بك هناك. قد تعني النقطة الصفراء ببساطة تعديلات لم تُنشر، وحالة النشر لا تضمن نجاح تنفيذ البريد الإلكتروني أو LLM التالي. ماذا تقول نصيحة النقطة الحمراء عند توقفها؟
كائن سير العمل من واجهة برمجة التطبيقات يحتوي على علم نشط، لذا تحقق من ذلك في مدتك البالغة عشر دقائق وأعد تفعيله إذا كان خاطئًا. Active يخبرك فقط بأنه مُشغّل، وليس أنه سليم. سحب عمليات التنفيذ الأخيرة والتحقق من نجاح حديث هو اختبار أفضل. حاسوب محمول ينام سيستمر في إزعاجك أيضًا.
@liar666 رمز 401 يعني أن الطلب لا يحمل مفتاح API في رأس الطلب الذي يتوقعه n8n. في عقدة HTTP Request، لا تستخدم بيانات اعتماد عامة “Predefined Credential” — بدلاً من ذلك، اضبط Authentication على “Generic Credential Type” → “Header Auth”، مع Name X-N8N-API-KEY و Value = مفتاح API الخاص بك في n8n. أو استخدم نوع بيانات الاعتماد المخصص “n8n API” إذا كانت نسخة العقدة الخاصة بك توفره.
هناك بضع نقاط يجب التحقق منها: يجب إنشاء المفتاح ضمن Settings → n8n API (وليس كلمة مرور المستخدم)، وإذا كانت النسخة الخاصة بك خلف خادم وكيل عكسي، تأكد من عدم قيام الوكيل بحذف رأس X-N8N-API-KEY قبل وصوله إلى n8n. يمكنك التحقق بسرعة باستخدام curl من نفس الجهاز: curl -H "X-N8N-API-KEY: <key>" http://localhost:5678/api/v1/workflows — إذا أرجع 200، فالمفتاح بخير والمشكلة فقط في كيفية إرسال العقدة له.