تصور کنید یک اتصال شبکه ناپایدار که تنها ۱۱ ثانیه طول می‌کشد، در یک هفته منجر به ایجاد ۴ تیکت پشتیبانی تکراری و ۳ عذرخواهی بی مورد شود. این سناریو یک نقص حیاتی در نحوه مدیریت شکست‌ها توسط توسعه‌دهندگان را فاش می‌کند؛ مشکلی که طبق راهنمای فنی منتشر شده در dev.to در ۱۵ سپتامبر ۲۰۲۶، اصلاً به استدلال مدل‌های زبانی مربوط نمی‌شود. در عوض، این مشکل ناشی از یک درک بنیادین و نادرست از معناشناسی انتقال داده (Transport Semantics) در حلقه‌های عامل است.
این موضوع در ادامه پوشش‌های قبلی ما درباره‌ی نحوه جایگزینی حلقه‌های عامل با توپولوژی سیستم‌فایل توسط meclaw برای مدیریت وضعیت قرار می‌گیرد. این مسئله خطر تکیه بر منطق ساده‌ی «تلاش مجدد» (Naive Retry Logic) را برجسته می‌کند. در یک محیط عملیاتی، یک فراخوانی «شکست‌خورده» لزوماً به این معنا نیست که عملیات انجام نشده است؛ بلکه اغلب به این معناست که تأییدیهٔ نهایی در مسیر بازگشت گم شده است.
مدل سه-حالتی شکست
بسیاری از توسعه‌دهندگان، فراخوانی ابزار را به صورت دوحالتی (موفق یا شکست) مدل‌سازی می‌کنند. اما در واقعیت، هر درخواست در یکی از این سه حالت است:
- تلاش شده (Attempted): کلاینت بایت‌های درخواست را ارسال کرده است.
- تثبیت شده (Committed): سرور وضعیت را تغییر داده است (مثلاً تیکت در دیتابیس ساخته شده است).
- تأیید شده (Acknowledged): کلاینت تأییدیهٔ تثبیت را دریافت کرده است.
خطر اصلی در شکاف بین «تثبیت» و «تأیید» نهفته است. کلاینت در تمام مدت فقط حالت‌های ۱ و ۳ را مشاهده می‌کند. اگر بعد از ثبت در پایگاه‌داده اما قبل از رسیدن پاسخ به کلاینت، یک افت شبکه (Network Drop) رخ دهد، کلاینت یک «تایم‌اوت» (Timeout) می‌بیند. برای عامل (Agent) — شبیه دستیاری که دستور را گرفته اما نمی‌داند آیا اجرا شده یا نه — این وضعیت دقیقاً مشابه درخواستی است که هرگز از لپ‌تاپ خارج نشده است. در نتیجه، عامل یک تلاش مجدد را تحریک می‌کند که منجر به ایجاد یک رکورد تکراری می‌شود. شما نمی‌توانید این دو سناریو را از سمت کلاینت از یکدیگر تشخیص دهید.
افشای باورهای غلط درباره تلاش مجدد
برخی توسعه‌دهندگان تصور می‌کنند چون برخی نقاط اتصال (Endpoints) رایگان هستند، تلاش مجدد هزینه‌ای ندارد. اما ارز واقعی اینجا پول نیست، بلکه «بودجه گام‌ها» (Step Budgets) و اعتماد به گزارش‌های بازرسی (Audit Logs) است. هر تلاش تکراری هزینه‌ای واقعی دارد: یک اثر جانبی تکراری (مثل یک کامیت یا ارسال ایمیل)، مصرف یک گام از بودجه حلقه و تخریب گزارشات بازرسی که در آن تعداد گام‌ها دیگر با اثرات واقعی همخوانی ندارد. این عدم کنترل بر گام‌های حلقه می‌تواند منجر به بحران‌های شدیدی شود، مشابه آنچه در تحلیل پس‌مرگ یک حلقه بی‌نهایت که بودجه توکن‌ها را سوزاند مشاهده کردیم. مردم عبارت «سطح رایگان» را می‌شنوند و فکر می‌کنند هزینه‌ای وجود ندارد، اما هزینه‌های واقعی در واقع زمان واقعی (Wall-clock time) و یکپارچگی لاگ‌ها هستند.
اشتباه رایج دیگر، تلاش برای حل این مشکل از طریق مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — است. گفتن این جمله به مدل که «اگر مطمئن نیستی دوباره تلاش نکن»، فقط یک حالت شکست جدید ایجاد می‌کند؛ جایی که عامل فراخوانی‌هایی را رها می‌کند که در واقع موفق شده بودند. پرامپت نمی‌تواند معناشناسی انتقال داده در زیرساخت اینترنت را تغییر دهد؛ منطق تلاش مجدد باید در کد باشد، نه در پرامپت سیستمی.
پیاده‌سازی کلیدهای Idempotency
برای حل این بحران، هر فراخوانی ابزار که عملیات «نوشتن» (Non-read) انجام می‌دهد، به یک کلید Idempotency (تکرارناپذیری) پایدار نیاز دارد. این الگو که توسط پردازشگرهای پرداخت محبوب شد، برای هر عملیاتی که چیزی را به صف اضافه می‌کند یا در فایلی می‌نویسد که تکرار آن قابل تشخیص است، ضروری است. مثال‌هایی از این ابزارها عبارتند از:
create_ticket(ایجاد تیکت)send_email(ارسال ایمیل)push_commit(ارسال کامیت)insert_row(درج ردیف)
عملیات «خواندن» ذاتاً تکرارناپذیر هستند، اما «نوشتن» این‌طور نیست. تفکیک ابزارها به این دو دسته قبل از نوشتن سیاست تلاش مجدد، می‌تواند کل آخر هفته‌های شما را از عیب‌یابی‌های طولانی نجات دهد. برای بهینه‌سازی این فرآیند، می‌توان از رویکردهای تبدیل لاگ‌های گران‌قیمت به تست‌های رایگان استفاده کرد تا نقاط شکست در عملیات نوشتن را بدون هزینه اضافی شناسایی کرد.
برای پیاده‌سازی صحیح، این قوانین سخت‌گیرانه را دنبال کنید:
- کلید را قبل از اولین تلاش تولید کنید، نه داخل حلقه تلاش مجدد.
- کلید را در کنار فراخوانی ابزار ذخیره (Persist) کنید تا در صورت ری‌استارت شدن سیستم، دوباره از همان کلید استفاده شود.
- فقط خطاهای خاص را تکرار کنید: خطاهای انتقال، خطاهای ۵xx (سرور) و ۴۲۹ (محدودیت نرخ) باید با تأخیر تصادفی (Backoff and Jitter) تکرار شوند.
- هرگز خطاهای ۴xx را تکرار نکنید، چون درخواست توسط سرور درک شده و رد شده است.
- حذف تکرار (Dedupe) را در سمت سرور انجام دهید، بر اساس همان کلید پایدار و با پشتیبانی یک ذخیره‌ساز واقعی.
جدول تصمیم‌گیری برای مدیریت شکست
وقتی یک فراخوانی شکست می‌خورد، اقدام شما باید بر اساس مشاهده باشد:
- تایم‌اوت / قطع اتصال: احتمالاً اثر تثبیت شده است $
ightarrow$ تلاش مجدد با همان کلید. - خطای ۴۲۹ (Too Many Requests): معمولاً تثبیت نشده است $
ightarrow$ توقف کوتاه (Back off)، سپس تلاش مجدد با همان کلید. - خطاهای ۵۰۰ / ۵۰۲ / ۵۰۳: احتمالاً تثبیت شده است $
ightarrow$ تلاش مجدد با همان کلید. - خطاهای ۴۰۰ / ۴۲۲: تثبیت نشده است $
ightarrow$ اصلاح درخواست، عدم تلاش مجدد. - خطای ۴۰۹ (Conflict): احتمالاً تثبیت شده است $
ightarrow$ فرض کنید عملیات قبلاً انجام شده است.
تست با نقطه اتصال خصمانه
یک ابزار تست پایتون (retry_ledger.py) که تنها از کتابخانه‌های استاندارد استفاده می‌کند، با شبیه‌سازی یک سرور «خصمانه»، این موضوع را ثابت می‌کند. این سرور طوری طراحی شده که اثر را تثبیت می‌کند اما قبل از ارسال تأییدیه، خطای ۵۰۳ برمی‌گرداند.
در یک سرور ساده (Naive)، این اتفاق منجر به ۲ اثر جانبی برای یک عملیات منطقی می‌شود. اما یک سرور با قابلیت حذف تکرار، با استفاده از کلید Idempotency، به‌درستی فقط ۱ اثر را ثبت می‌کند. این شبیه‌سازی ثابت می‌کند که دیدن اینکه یک سرور ساده عدد «۲» را گزارش می‌دهد، متقاعدکننده‌تر از هر بحث تئوریک است.
زیرساخت و استقرار
برای کسانی که عامل و سرور خود را در یک مکان مستقر می‌کنند — مثلاً با استفاده از گزینه‌های دسترسی رایگان به مدل و سرور MonkeyCode — یک تله نهایی وجود دارد: دیکشنری‌های حذف تکرار در حافظه (In-memory)، با ری‌استارت شدن پاک می‌شوند. اگر کلید و نتیجه را قبل از ارسال درخواست روی دیسک ننویسید، سرور رایگان شما به یک «کارخانه تولید تکرار» تبدیل می‌شود.
چه زمانی از این پیچیدگی صرف‌نظر کنیم؟
اضافه کردن کلیدها، حجم نوشتن را دو برابر کرده و یک سربار جست‌وجو (Lookup overhead) به هر فراخوانی اضافه می‌کند. این سربار واقعی است و در موارد زیر غیرضروری است:
- اگر تمام ابزارهای شما فقط «خواندنی» (Read-only) هستند.
- اگر اجرای مجدد کل فرآیند از ابتدا، ارزان و تمیز است.
- اگر تکرارها در حوزه کاری خاص شما واقعاً بی‌ضرر هستند.
در این موارد، تلاش مجدد بدون کلید پذیرفتنی است. اما برای سیستم‌های عملیاتی (Production)، یک دیکشنری محلی در سطح پروسه کافی نیست و به یک ذخیره‌ساز بادوام مشترک (Shared Durable Store) با یک پنجره زمانی برای نگهداری داده‌ها نیاز است.
این تغییر رویکرد، مسئولیت پایداری را از دوش پرامپت به دوش کد منتقل می‌کند. با اجبار به اجرای «دقیقاً یک‌بار» (Exactly-once semantics) در سمت سرور و ارائه کلیدهای پایدار از سمت کلاینت، توسعه‌دهندگان می‌توانند جلوی عذرخواهی‌های تکراری عامل‌هایشان برای یک اشتباه واحد را بگیرند.
گام بعدی شما
- تمام ابزارهای «نوشتنی» (Write) در سیستم خود را لیست کرده و برای هر کدام یک استراتژی تولید کلید Idempotency تعریف کنید.
- منطق Retry را از پرامپت‌های سیستمی حذف کرده و آن را به لایه Middleware کد منتقل کنید.
- با استفاده از یک سرور شبیه‌ساز، سناریوی «تثبیت بدون تأیید» را تست کنید تا از صحت حذف تکرار مطمئن شوید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو