وقتی درخواست مدل timeout می‌شود، لزوماً اجرای آن در سرور متوقف نشده است. تکرار فوری می‌تواند فقط هزینه اضافی بسازد یا یک اقدام حساس را دوباره اجرا کند. پیش از retry، خطای شبکه را از وضعیت نامشخص کار جدا کنید و برای درخواست خواندنی و نوشتنی سیاست متفاوت داشته باشید.
روش اجرا و تصمیم‌گیری
برای اتصال، دریافت پاسخ و کل مدت کار مهلت جدا تعریف کنید. مهلت باید با رفتار واقعی سرویس و نیاز کاربر سازگار باشد؛ عدد یکسان برای همه ابزارها مناسب نیست. شناسه درخواست و زمان شروع را ثبت کنید تا بتوانید پاسخ دیررس را به همان کار وصل کنید.
خطاهای قابل تکرار را از خطای ورودی و مجوز جدا کنید. ورودی نامعتبر با صبرکردن درست نمی‌شود. برای خطای موقت، تعداد تلاش محدود و فاصله افزایشی همراه پراکندگی تصادفی تعیین کنید. اگر ارائه‌دهنده زمان انتظار مشخص کرده، قرارداد آن را رعایت کنید.
عملیات نوشتنی باید شناسه یکتای اقدام و روش بررسی وضعیت مقصد داشته باشد. پس از قطع شبکه، ابتدا معلوم کنید کار انجام شده یا نه. اگر سرویس از کلید idempotency پشتیبانی می‌کند، همان کلید کار قبلی را برای retry نگه دارید؛ ساخت کلید تازه ممکن است اقدام تازه محسوب شود. این قابلیت را برای همه APIها فرض نکنید.
نمونهٔ ساختگی و قابل تکرار
فرض کنید ابزار آزمایشی باید یک درخواست بی‌اثر ثبت کند. شبکه بعد از ارسال قطع می‌شود و پاسخ نمی‌رسد. برنامه وضعیت را «نامشخص» می‌گذارد، با شناسه کار مقصد را بررسی می‌کند و می‌بیند ثبت انجام شده است؛ در نتیجه ثبت دوباره نمی‌کند. در حالت دوم مقصد هیچ رکوردی ندارد و طبق قرارداد مجاز، retry محدود با همان شناسه انجام می‌شود. پیام کاربر در هر دو حالت وضعیت واقعی را می‌گوید؛ نبود پاسخ HTTP را شکست قطعی عملیات معرفی نمی‌کند.
محدودیت‌ها و خطاهای رایج
نمونه حاضر الگوی طراحی است، نه نسخه تنظیم برای یک SDK مشخص. مهلت و رفتار retry ارائه‌دهنده را از مستندات همان نسخه بخوانید. هیچ آزمون تکرار را با پرداخت، پیام یا تماس واقعی انجام ندهید؛ محیط نمونه و ابزار بی‌اثر برای این بررسی کافی است.
کنترل پیش از استفاده
| کنترل | معیار پذیرش |
|---|---|
| مهلت | زمان اتصال و کل کار با شناسه اجرای مشخص ثبت شوند. |
| تکرار | خطای موقت با سقف تلاش و فاصله مناسب دوباره بررسی شود. |
| اثر بیرونی | وضعیت مقصد و کلید کار، مانع اجرای دوباره اقدام حساس شوند. |
کاربرگ همراه
کاربرگ برای آزمایش سناریوی قطع قبل و بعد از ارسال است. ستون وضعیت مقصد را مستقل از خطای مرورگر پر کنید. اگر وضعیت قابل تعیین نیست، مورد را برای بررسی نگه دارید و موفق یا ناموفق قطعی برچسب نزنید.
دریافت کاربرگ CSV این راهنما — داده‌های داخل فایل نمونهٔ ساختگی‌اند. نسخهٔ اصلی را نگه دارید و برای آزمون خودتان یک کپی بسازید.
منبع و ادامهٔ کار
Google SRE: مدیریت اضافه‌بار؛ Stripe: درخواست‌های تکرارپذیر امن. تاریخ بررسی منابع: ۱ نوامبر ۲۰۲۶.
اگر کاربرد شما پاسخ‌گویی به مشتری است، مسیر مرتبط اپرا را ببینید و مسئله و محدودیت‌های همین کاربرگ را برای بررسی در دمو همراه داشته باشید.