بحث $tries در Jobهای لاراول دوباره داغ شده و معمولاً وقتی عددهای بزرگی مثل ۶۰ یا ۱۰۰ دیده می‌شود، سریع برچسب «طراحی بد» می‌خورد.
اما واقعیت کمی دقیق‌تر از این قضاوت ساده است.

در حالت عادی، استفاده از $tries بزرگ می‌تواند نشانه‌ی این باشد که داریم یک مشکل ریشه‌ای را با retry پنهان می‌کنیم. این اتفاق معمولاً در Jobهایی می‌افتد که یا idempotent نیستند یا مرز خطاهایشان مشخص نیست.

اما در بعضی سناریوها، retry کاملاً منطقی است.
مثلاً وقتی Job با یک سرویس خارجی یا API بیرونی کار می‌کند. در این شرایط، در دسترس نبودن موقت سرویس چیز عجیبی نیست و retry با فاصله‌ی زمانی حساب‌شده می‌تواند درخواست را در اجرای بعدی موفق کند.

یک الگوی جالب این است که $tries > 1 را همراه با $maxExceptions = 1 استفاده کنیم.
در این حالت Job فقط زمانی دوباره اجرا می‌شود که خودمان به‌صورت کنترل‌شده release() را صدا بزنیم و اگر یک exception غیرمنتظره رخ دهد، Job وارد چرخه‌ی retry بی‌پایان نمی‌شود.

نکته‌ی مهم اینجاست که retry زیاد بدون backoff یعنی مصرف منابع بدون حل مسئله. retry محدود، همراه با backoff منطقی یعنی سیستم مقاوم و قابل اتکا.

در نهایت، مسئله این نیست که $tries چند است.
مسئله این است که آیا retry بخشی از طراحی آگاهانه‌ی سیستم است یا فقط واکنشی عجولانه به خطاها.

@DevTwitter | <Mohammad Javad Ranjbar/>