هنگام ساخت Workflow در n8n، ممکن است همه مراحل اتوماسیون همیشه با موفقیت اجرا نشوند. برای مثال، تصور کنید یک Workflow اطلاعات سفارش‌های فروشگاه اینترنتی را دریافت می‌کند و سپس آن‌ها را به یک API خارجی ارسال می‌کند. اگر سرور مقصد برای چند ثانیه از دسترس خارج شود، درخواست ممکن است با خطا مواجه شود؛ حتی اگر اطلاعات سفارش و تنظیمات اتصال کاملاً صحیح باشند.
در چنین شرایطی، اجرای دوباره درخواست می‌تواند مشکل را برطرف کند. اما اگر قرار باشد برای هر خطای موقت، کاربر به‌صورت دستی Workflow را اجرا کند، مدیریت اتوماسیون دشوار و زمان‌بر خواهد شد.
در n8n قابلیتی به نام Retry On Fail وجود دارد که به کمک آن می‌توانید برای اجرای ناموفق یک Node، تلاش مجدد خودکار تعریف کنید.
در این آموزش یاد می‌گیرید Retry On Fail چیست، چگونه آن را تنظیم کنید، چه زمانی استفاده از آن مناسب است و چگونه از اجرای تکراری عملیات حساس جلوگیری کنید.
Retry در n8n چیست؟
Retry به معنی تلاش مجدد برای انجام یک عملیات پس از شکست آن است.
فرض کنید یک Node از نوع HTTP Request برای دریافت اطلاعات از یک API استفاده می‌کند. اگر درخواست به دلیل یک اختلال موقت شبکه ناموفق شود، ممکن است اجرای دوباره آن موفقیت‌آمیز باشد.
به‌جای اینکه هر بار Workflow را به‌صورت دستی اجرا کنید، می‌توانید Retry On Fail را برای Node موردنظر فعال کنید تا n8n مطابق تنظیمات تعیین‌شده، در صورت بروز خطا دوباره تلاش کند.
این قابلیت در شرایطی مانند موارد زیر مفید است:
- اختلال موقت در ارتباط شبکه
- پاسخ موقتاً ناموفق از API
- محدودیت تعداد درخواست‌ها از طرف سرویس مقصد
- بار زیاد یا ناپایداری موقت سرور خارجی
- شکست موقت در ارتباط با یک سرویس وابسته
البته Retry تمام خطاها را برطرف نمی‌کند. اگر API Key اشتباه باشد، آدرس Endpoint وجود نداشته باشد یا داده ارسالی نامعتبر باشد، تلاش مجدد معمولاً مشکل اصلی را حل نخواهد کرد.
بنابراین، استفاده صحیح از Retry مستلزم شناخت نوع خطا و انتخاب تنظیمات متناسب با آن است.
تفاوت Retry On Fail با Error Handling چیست؟
Retry On Fail و Error Handling هر دو برای مدیریت شرایط ناموفق در Workflow کاربرد دارند، اما وظیفه آن‌ها یکسان نیست.
| قابلیت | کاربرد |
|---|---|
| Retry On Fail | تلاش مجدد برای اجرای Node ناموفق |
| Error Workflow | رسیدگی به خطای اجرای Workflow، مانند ثبت خطا یا ارسال هشدار |
| Stop And Error | ایجاد یک خطای کنترل‌شده و توقف اجرای جاری |
| IF | بررسی شرط‌ها و هدایت داده به مسیر مناسب |
برای مثال، اگر درخواست HTTP به دلیل یک مشکل موقت ناموفق شود، Retry On Fail می‌تواند برای تلاش مجدد استفاده شود.
اما اگر تمام تلاش‌ها ناموفق باشند، ممکن است لازم باشد خطا ثبت شود یا مدیر سیستم از مشکل مطلع شود. در این شرایط، استفاده از سازوکارهای Error Handling در کنار Retry می‌تواند مفید باشد.
نکته مهم این است که Retry جایگزین مدیریت خطا نیست؛ بلکه یکی از ابزارهای آن محسوب می‌شود.
چگونه Retry On Fail را در n8n فعال کنیم؟
برای مشاهده عملکرد این قابلیت، یک Workflow آزمایشی با HTTP Request ایجاد می‌کنیم.
مرحله اول: یک Workflow جدید بسازید
وارد پنل n8n شوید و یک Workflow جدید ایجاد کنید.
برای آزمایش، می‌توانید یک Manual Trigger به Workflow اضافه کنید تا اجرای آن با کلیک روی دکمه اجرای دستی آغاز شود.
سپس یک Node از نوع HTTP Request به Workflow اضافه کنید.
مرحله دوم: HTTP Request را تنظیم کنید
در تنظیمات HTTP Request، یک آدرس API معتبر وارد کنید که برای آزمایش شما مناسب باشد.
برای نمونه، می‌توانید از یک API آزمایشی عمومی استفاده کنید؛ البته در دسترس بودن آن به وضعیت سرویس و شبکه شما بستگی دارد.
در این مثال، هدف اصلی بررسی تنظیمات Retry است، نه آموزش یک API مشخص.
Method و سایر پارامترهای درخواست را مطابق نیاز خود تنظیم کنید.
مرحله سوم: تنظیمات Node را باز کنید
روی Node مربوط به HTTP Request کلیک کنید و وارد بخش تنظیمات آن شوید.
گزینه‌ای با عنوان Retry On Fail را پیدا کنید و آن را فعال کنید.
نام و محل دقیق تنظیمات ممکن است با توجه به نسخه n8n کمی متفاوت باشد.
مرحله چهارم: تعداد تلاش‌ها را تنظیم کنید
پس از فعال‌سازی Retry On Fail، تنظیمات مربوط به تعداد تلاش‌ها و فاصله زمانی بین آن‌ها را بررسی کنید.
دو گزینه مهم عبارت‌اند از:
- Max Tries: حداکثر تعداد تلاش‌های مجاز برای اجرای Node
- Wait Between Tries: فاصله زمانی بین تلاش‌ها
برای مثال، فرض کنید می‌خواهید در صورت شکست درخواست، Node حداکثر سه بار تلاش کند و فاصله بین تلاش‌ها یک ثانیه باشد.
در این صورت می‌توانید مقادیر زیر را در تنظیمات مربوطه قرار دهید:
| تنظیم | مقدار نمونه |
|---|---|
| Retry On Fail | فعال |
| Max Tries | 3 |
| Wait Between Tries | 1000 میلی‌ثانیه |
این مقادیر صرفاً نمونه آموزشی هستند و بهترین تنظیم برای همه APIها محسوب نمی‌شوند.
نکته: مقدار Max Tries را بر اساس نحوه نمایش این گزینه در نسخه خودتان تنظیم کنید. تعداد کل تلاش‌ها و تعداد تلاش‌های مجدد ممکن است در ابزارهای مختلف با اصطلاحات متفاوتی بیان شوند؛ بنابراین برای محاسبه دقیق تعداد درخواست‌ها، رفتار نسخه مورد استفاده را بررسی کنید.
مرحله پنجم: Workflow را اجرا کنید
Workflow را اجرا کنید و نتیجه Node را بررسی کنید.
اگر درخواست در اولین تلاش موفق شود، نیازی به تلاش مجدد نخواهد بود.
اگر درخواست ناموفق باشد و خطا در محدوده رفتار قابل‌تکرار Node قرار بگیرد، n8n می‌تواند مطابق تنظیمات، دوباره تلاش کند.
اگر تمام تلاش‌ها ناموفق باشند، Node در نهایت شکست‌خورده باقی می‌ماند و باید بر اساس تنظیمات Workflow، خطا را بررسی یا مدیریت کنید.
توجه داشته باشید که Retry تضمین نمی‌کند درخواست حتماً موفق خواهد شد؛ این قابلیت صرفاً امکان تلاش مجدد را فراهم می‌کند.
مثال عملی: تلاش مجدد هنگام خطای موقت API
فرض کنید یک فروشگاه اینترنتی دارید و Workflow شما پس از ثبت سفارش، اطلاعات آن را برای یک سرویس دیگر ارسال می‌کند.
فرایند به شکل زیر است:
- دریافت اطلاعات سفارش
- آماده‌سازی داده‌های سفارش
- ارسال اطلاعات به API مقصد
- ثبت نتیجه عملیات
ممکن است API مقصد گاهی به دلیل فشار کاری یا اختلال موقت پاسخ مناسبی ندهد.
در این حالت، می‌توانید Retry On Fail را روی Node ارسال درخواست فعال کنید.
<box border radius="lg" padding={3} gap={2}>
<box background="surface-secondary" radius="md" padding={3} align="center" gap={1}>
<icon name="play-circle" size="xl" />
شروع Workflow
<text color="secondary" size="sm">دریافت سفارش</text>
</box>
<box align="center">
<icon name="arrow-down" size="lg" color="secondary" />
</box>
<box background="surface" border radius="md" padding={3} align="center" gap={1}>
<icon name="send" size="xl" />
HTTP Request
<text color="secondary" size="sm">ارسال اطلاعات به API</text>
</box>
<box align="center">
<icon name="arrow-down" size="lg" color="secondary" />
</box>
<grid columns={2} gap={2}>
<grid-item>
<box background="surface" border radius="md" padding={3} align="center" gap={1}>
<icon name="check-circle" color="success" size="xl" />
درخواست موفق
<text color="secondary" size="sm">ادامه پردازش</text>
</box>
</grid-item>
<grid-item>
<box background="surface" border radius="md" padding={3} align="center" gap={1}>
<icon name="refresh-cw" size="xl" />
درخواست ناموفق
<text color="secondary" size="sm">تلاش مجدد طبق تنظیمات</text>
</box>
</grid-item>
</grid>
</box>
در این سناریو، اگر درخواست در یکی از تلاش‌های مجدد موفق شود، Workflow می‌تواند از همان Node به مراحل بعدی ادامه دهد.
اما اگر درخواست پس از تمام تلاش‌ها همچنان ناموفق باشد، باید مسیر رسیدگی به شکست نهایی را نیز طراحی کنید؛ برای مثال، ارسال هشدار یا ثبت سفارش برای بررسی دستی.
این موضوع به‌ویژه زمانی اهمیت دارد که Workflow مسئول عملیات مهمی مانند پردازش سفارش یا هماهنگ‌سازی اطلاعات باشد.
Retry در خطاهای مختلف API
یکی از اشتباهات رایج این است که Retry را برای همه خطاها به یک شکل تنظیم کنیم.
در عمل، نوع خطا تأثیر زیادی بر مناسب بودن تلاش مجدد دارد.
خطای 500؛ خطای داخلی سرور
خطای HTTP 500 معمولاً نشان می‌دهد سرور مقصد هنگام پردازش درخواست با مشکلی مواجه شده است.
اگر مشکل موقتی باشد، اجرای دوباره درخواست ممکن است موفقیت‌آمیز باشد. بااین‌حال، Retry تضمین نمی‌کند خطا برطرف شود.
خطای 429؛ محدودیت تعداد درخواست‌ها
خطای 429 معمولاً به معنی عبور از محدودیت تعداد درخواست‌های مجاز است.
در چنین شرایطی، ارسال فوری درخواست‌های بیشتر ممکن است مشکل را تشدید کند.
بهتر است فاصله زمانی بین تلاش‌ها را متناسب با سیاست سرویس تنظیم کنید و اگر API هدر Retry-After ارائه می‌دهد، رفتار توصیه‌شده آن سرویس را در طراحی Workflow در نظر بگیرید.
فعال بودن Retry On Fail به‌تنهایی به معنی رعایت خودکار تمام سیاست‌های اختصاصی API نیست؛ نحوه استفاده از اطلاعات پاسخ و زمان‌بندی مجدد را باید بر اساس امکانات Node و نسخه n8n بررسی کنید.
خطای 401؛ احراز هویت ناموفق
خطای 401 معمولاً به مشکل احراز هویت مربوط است.
برای مثال، ممکن است API Key اشتباه باشد یا توکن دسترسی اعتبار خود را از دست داده باشد.
در این حالت، تلاش مجدد با همان اطلاعات نامعتبر معمولاً کمکی نمی‌کند. ابتدا Credential و روش احراز هویت را بررسی کنید.
خطای 400؛ درخواست نامعتبر
خطای 400 معمولاً به اشکال در درخواست ارسال‌شده مربوط می‌شود؛ مانند داده ناقص، نوع داده اشتباه یا پارامتر نامعتبر.
اگر درخواست بدون تغییر تکرار شود، احتمال دارد همان خطا دوباره رخ دهد.
بهتر است داده‌ها، ساختار JSON و پارامترهای درخواست را بررسی و علت اصلی را اصلاح کنید.
خطای Timeout
Timeout زمانی اتفاق می‌افتد که درخواست در محدوده زمانی تعیین‌شده به نتیجه نرسد.
این وضعیت ممکن است ناشی از اختلال شبکه، کندی سرویس یا طولانی شدن پردازش باشد.
تلاش مجدد می‌تواند مفید باشد، اما باید توجه کنید که در برخی موارد، سرور مقصد عملیات را انجام داده است و فقط پاسخ آن به n8n نرسیده است. همین مسئله می‌تواند باعث ایجاد عملیات تکراری شود.
جلوگیری از اجرای تکراری عملیات هنگام Retry
این بخش یکی از مهم‌ترین نکات استفاده از Retry در پروژه‌های واقعی است.
فرض کنید Workflow شما برای یک مشتری، پرداختی را ثبت می‌کند یا سفارشی را به یک سیستم خارجی ارسال می‌کند.
درخواست ارسال می‌شود، اما پاسخ API به دلیل اختلال شبکه دریافت نمی‌شود. n8n ممکن است درخواست را ناموفق تشخیص دهد و دوباره تلاش کند؛ درحالی‌که سرور مقصد عملیات اولیه را انجام داده است.
اگر API مقصد درخواست تکراری را به‌عنوان عملیات جدید در نظر بگیرد، ممکن است نتیجه ناخواسته‌ای ایجاد شود.
برای مثال:
- ثبت دو سفارش مشابه
- ارسال چندباره یک پیام
- ایجاد رکوردهای تکراری در سیستم مقصد
- انجام دوباره یک عملیات حساس
- ثبت چندباره یک تراکنش، در صورت نبود کنترل‌های مناسب
راهکار اول: استفاده از Idempotency Key
اگر API مقصد از Idempotency Key پشتیبانی می‌کند، برای درخواست‌های حساس از آن استفاده کنید.
Idempotency Key شناسه‌ای است که به سرویس مقصد کمک می‌کند درخواست‌های تکراری مربوط به یک عملیات را تشخیص دهد و از اجرای مجدد ناخواسته آن جلوگیری کند؛ البته رفتار دقیق به پیاده‌سازی API بستگی دارد.
برای مثال، می‌توانید یک شناسه پایدار برای هر سفارش داشته باشید و همان شناسه را در تلاش‌های مجدد همان عملیات ارسال کنید.
نکته مهم این است که شناسه نباید در هر تلاش مجدد به‌صورت تصادفی تغییر کند؛ در غیر این صورت، سرویس مقصد ممکن است هر درخواست را عملیاتی مستقل تلقی کند.
راهکار دوم: بررسی وضعیت عملیات پیش از تکرار
اگر API مقصد از Idempotency Key پشتیبانی نمی‌کند، ممکن است لازم باشد قبل از اجرای دوباره عملیات، وضعیت آن را بررسی کنید.
برای مثال، پس از خطای نامشخص در ارسال سفارش، می‌توانید با استفاده از شناسه سفارش بررسی کنید آیا سفارش قبلاً در سیستم مقصد ثبت شده است یا خیر.
این راهکار فقط زمانی قابل‌اتکا است که سرویس مقصد امکان بررسی وضعیت را فراهم کند و بررسی وضعیت نیز به‌درستی پیاده‌سازی شده باشد.
راهکار سوم: استفاده از شناسه یکتا در سیستم خودتان
در بعضی معماری‌ها می‌توانید برای هر عملیات یک شناسه یکتا در پایگاه داده خودتان ذخیره کنید.
پیش از ثبت مجدد عملیات، وضعیت شناسه را بررسی کنید و با استفاده از محدودیت‌های مناسب پایگاه داده از ثبت تکراری جلوگیری کنید.
البته این راهکار باید متناسب با معماری سیستم طراحی شود؛ صرف بررسی ساده یک مقدار بدون کنترل هم‌زمانی، همیشه مانع ایجاد رکوردهای تکراری نمی‌شود.
نکته امنیتی و عملیاتی: برای عملیات مالی، پرداخت و ثبت سفارش، تنها به Retry On Fail تکیه نکنید. مدیریت تکرار عملیات باید با امکانات API مقصد و قواعد کسب‌وکار هماهنگ باشد.
چگونه Retry را در کنار Error Workflow استفاده کنیم؟
Retry و Error Workflow می‌توانند مکمل یکدیگر باشند.
فرض کنید یک Workflow اطلاعات سفارش را به API مقصد ارسال می‌کند. ابتدا Retry On Fail را برای درخواست فعال می‌کنید تا در صورت بروز خطای موقت، n8n دوباره تلاش کند.
اگر تمام تلاش‌ها ناموفق باشند، اجرای Workflow همچنان ممکن است با شکست مواجه شود. در این حالت، Error Workflow می‌تواند برای ثبت اطلاعات خطا یا ارسال هشدار استفاده شود؛ مشروط بر اینکه به‌درستی تنظیم شده باشد و شرایط خطا تحت پوشش آن قرار بگیرد.
ساختار مفهومی چنین فرایندی به این صورت است:
- Workflow اصلی شروع می‌شود.
- درخواست به API ارسال می‌شود.
- در صورت بروز خطای قابل‌تکرار، تلاش مجدد انجام می‌شود.
- اگر درخواست موفق شود، پردازش ادامه پیدا می‌کند.
- اگر اجرای Workflow در نهایت شکست بخورد، سازوکار مدیریت خطا می‌تواند برای ثبت گزارش یا اطلاع‌رسانی فعال شود.
برای مثال، Error Workflow می‌تواند نام Workflow ناموفق، اطلاعات اجرای مربوطه و پیام خطا را دریافت کند و به مدیر سیستم هشدار بدهد.
در طراحی این بخش، ساختار واقعی خروجی خطا را بررسی کنید و اطلاعات حساس مانند توکن‌های API یا رمزهای عبور را در پیام هشدار قرار ندهید.
اشتباهات رایج هنگام استفاده از Retry On Fail
۱. تنظیم تعداد تلاش‌های بسیار زیاد
اگر تعداد تلاش‌ها بیش از حد زیاد باشد، اجرای Workflow ممکن است مدت زیادی درگیر یک Node بماند و فشار غیرضروری به سرویس مقصد وارد کند.
راهکار: تعداد تلاش‌ها را بر اساس اهمیت عملیات، محدودیت API و مدت زمانی که برای انجام فرایند در نظر گرفته‌اید، انتخاب کنید.
۲. انتخاب فاصله زمانی بسیار کوتاه
تکرار سریع درخواست‌ها در شرایطی مانند خطای 429 یا فشار زیاد سرور می‌تواند وضعیت را بدتر کند.
راهکار: فاصله زمانی مناسبی انتخاب کنید و سیاست محدودیت درخواست‌های API را در نظر بگیرید.
۳. استفاده از Retry برای خطاهای دائمی
اگر اطلاعات احراز هویت اشتباه باشد یا درخواست ساختار نامعتبری داشته باشد، تلاش مجدد معمولاً مشکل را حل نمی‌کند.
راهکار: ابتدا علت خطا را بررسی کنید و در صورت نیاز، داده یا تنظیمات اتصال را اصلاح کنید.
۴. نادیده گرفتن احتمال اجرای تکراری
در برخی درخواست‌ها ممکن است سرور مقصد عملیات را انجام داده باشد، اما پاسخ آن به n8n نرسیده باشد.
راهکار: برای عملیات حساس، از Idempotency Key یا سازوکار کنترل تکرار مناسب استفاده کنید.
۵. نداشتن برنامه برای شکست نهایی
اگر همه تلاش‌ها ناموفق باشند و هیچ گزارشی ثبت نشود، ممکن است عملیات مهمی بدون اطلاع تیم پشتیبانی باقی بماند.
راهکار: در کنار Retry، مسیر مناسبی برای ثبت خطا، ارسال هشدار یا بررسی دستی طراحی کنید.
بهترین روش‌های استفاده از Retry در پروژه‌های واقعی
برای اینکه Retry به بهبود پایداری Workflow کمک کند، نکات زیر را در نظر بگیرید:
- فقط برای Nodeهایی Retry را فعال کنید که تکرار اجرای آن‌ها منطقی است.
- تعداد تلاش‌ها و فاصله زمانی را بر اساس نوع سرویس تنظیم کنید.
- برای خطاهای دائمی، به‌جای تکرار بی‌پایان، علت اصلی را اصلاح کنید.
- محدودیت نرخ درخواست‌ها و دستورالعمل‌های API مقصد را رعایت کنید.
- برای عملیات حساس، احتمال اجرای تکراری را کنترل کنید.
- پس از شکست نهایی، اطلاعات لازم را ثبت و در صورت نیاز هشدار ارسال کنید.
- تنظیمات Retry را در محیط آزمایشی بررسی کنید و سپس در محیط اصلی به کار ببرید.
- در زمان ثبت خطا، از ذخیره غیرضروری اطلاعات محرمانه خودداری کنید.
همچنین اگر Workflow شما تعداد زیادی آیتم را پردازش می‌کند، بررسی کنید که تنظیمات Retry در سطح هر Node و نحوه پردازش آیتم‌ها چگونه بر زمان کلی اجرا و تعداد درخواست‌های ارسالی تأثیر می‌گذارند.
جمع‌بندی
قابلیت Retry On Fail در n8n به شما کمک می‌کند پس از شکست یک Node، اجرای مجدد آن را به‌صورت خودکار مدیریت کنید. این قابلیت برای خطاهای موقت شبکه، برخی خطاهای API و اختلال‌های گذرا می‌تواند مفید باشد.
با این حال، Retry جایگزین عیب‌یابی و مدیریت خطا نیست. اگر خطا ناشی از اطلاعات نامعتبر، احراز هویت اشتباه یا مشکل دائمی سرویس باشد، باید علت اصلی را برطرف کنید.
در Workflowهای مهم، Retry را همراه با ثبت خطا، اطلاع‌رسانی و کنترل عملیات تکراری طراحی کنید. به‌ویژه برای پرداخت، ثبت سفارش و عملیات مالی، از قابلیت‌های جلوگیری از تکرار درخواست در API مقصد یا راهکارهای مناسب معماری سیستم استفاده کنید.
سؤالات متداول
Retry On Fail در n8n چیست؟
Retry On Fail قابلیتی است که امکان تلاش مجدد خودکار برای اجرای ناموفق یک Node را فراهم می‌کند. تعداد تلاش‌ها و فاصله زمانی بین آن‌ها از طریق تنظیمات مربوطه مشخص می‌شود.
Max Tries در n8n چه کاربردی دارد؟
Max Tries برای تعیین حداکثر تعداد تلاش‌های مجاز استفاده می‌شود. برای تفسیر دقیق تعداد تلاش‌ها باید رفتار و توضیحات همان گزینه را در نسخه مورد استفاده بررسی کنید.
Wait Between Tries چیست؟
این گزینه فاصله زمانی بین تلاش‌های مجدد را مشخص می‌کند. مقدار مناسب به نوع خطا، محدودیت API مقصد و زمان قابل‌قبول برای تکمیل Workflow بستگی دارد.
آیا Retry On Fail همه خطاها را برطرف می‌کند؟
خیر. تلاش مجدد ممکن است خطاهای موقت را برطرف کند، اما برای خطاهایی مانند Credential نامعتبر، درخواست نادرست یا دسترسی غیرمجاز معمولاً باید علت اصلی اصلاح شود.
آیا استفاده از Retry ممکن است باعث اجرای دوباره سفارش شود؟
بله، اگر درخواست اولیه در سرویس مقصد انجام شده باشد اما پاسخ به n8n نرسیده باشد، تکرار درخواست می‌تواند عملیات را دوباره اجرا کند. برای جلوگیری از این مشکل، از Idempotency Key یا روش کنترل تکرار مناسب استفاده کنید.
تفاوت Retry On Fail با Error Workflow چیست؟
Retry On Fail برای تلاش مجدد در اجرای Node استفاده می‌شود؛ در حالی که Error Workflow برای رسیدگی به خطاهای اجرای Workflow، مانند ثبت اطلاعات خطا و ارسال هشدار، کاربرد دارد.
آیا می‌توان Retry را برای HTTP Request فعال کرد؟
بله، در تنظیمات Node مربوط به HTTP Request می‌توانید در نسخه‌های پشتیبانی‌شده Retry On Fail را فعال کنید و تعداد تلاش‌ها و فاصله زمانی را تنظیم کنید. انتخاب تنظیمات مناسب باید با نوع API و رفتار خطا هماهنگ باشد.
