ما هي مدة انتظار تنفيذ سير العمل القصوى على n8n Cloud Trial و Starter؟

مرحبا،

أنا حالياً أستخدم نسخة تجريبية n8n Cloud لمدة 14 يوم وأقيّم خطة Starter لسير عمل أتمتة تحريري.

قد يحتوي سير العمل على عدة استدعاءات API و LLM متسلسلة وقد يستغرق أكثر من خمس دقائق للانتهاء.

هل يمكنك من فضلك تأكيد ما يلي:

  1. ما هي مدة التنفيذ القصوى لسير العمل على نسخة n8n Cloud التجريبية؟
  2. ما هي مدة التنفيذ القصوى في خطة Starter؟
  3. هل ينطبق انقطاع المهلة الزمنية بشكل مستقل على كل سير عمل وسير عمل فرعي، أم على سلسلة التنفيذ بأكملها؟
  4. ماذا يحدث عندما يصل سير العمل إلى هذا الحد؟
  5. هل يمكن زيادة انقطاع التنفيذ على خطة Starter أو Pro، أم فقط على Enterprise؟

أنا أسأل عن إجمالي وقت تنفيذ سير العمل في الخلفية، وليس انقطاع استجابة HTTP من webhook.

شكراً لك.

مرحبا @projetosaberebemesta أهلا وسهلا!
رقم 5 دقائق قديم الآن. Cloud لا يفرض حد تنفيذ قصير على Trial أو Starter، لذا فإن التشغيل مع عدة استدعاءات API و LLM متتالية تتجاوز خمس دقائق سينتهي بشكل طبيعي.
انظر إلى هذا:

المهل الزمنية اختيارية لكل workflow: Settings > Timeout Workflow > Timeout After. يحدد Cloud القيمة القصوى التي يمكنك اختيارها لكل خطة، ولا يمكنك رفعها أكثر من ذلك على Cloud لأن متغيرات البيئة غير معرضة هناك. EXECUTIONS_TIMEOUT و EXECUTIONS_TIMEOUT_MAX موجودة فقط على self-hosted. للحد الأقصى الدقيق في خطتك، اطلب من help@n8n.io.
كل workflow له إعداد timeout خاص به، و workflow يتم استدعاؤه بواسطة عقدة Execute Sub-workflow يعمل كتنفيذ خاص به، لذا فإن timeout الـ sub-workflow ينطبق على الـ sub-workflow بينما ساعة الأب تستمر طوال الوقت الذي تنتظر فيه.
عند الوصول إلى المهلة الزمنية، يلغي n8n التنفيذ بمجرد انتهاء العقدة الحالية. يتم وضع علامة عليها كملغاة ولا شيء يستأنف تلقائيا.
القيد الحقيقي على Trial و Starter هو الذاكرة وليس الوقت: كلاهما يحتوي على 320MiB RAM. سلاسل التحرير الطويلة تموت هناك أولا، لذا ادفع الخطوات الثقيلة إلى sub-workflows التي تعيد نتائج صغيرة فقط.

حدود لكل خطة إذا كنت تزن Starter مقابل Pro: