آیا آن ارسالِ زمان‌تمام‌شده واقعاً کار شما را ذخیره کرد؟

دکمه می‌چرخد، برگه خطا نشان می‌دهد و فرمی که ده دقیقه صرف پر کردنش کرده بودید از دست رفته است. آنچه نمی‌دانید این است که آیا نوشتن پیش از قطع اتصال انجام شده یا نه. برخورد با این ناشناخته به‌عنوان شکست همان روشی است که دیدگاه‌های تکراری، سفارش‌های دوتایی و تیکت‌های پشتیبانی مکرر ایجاد می‌شود.

به ترتیبی ثابت بازیابی کنید: متن را نگه دارید، نتیجه را پیدا کنید و تنها پس از آن تصمیم بگیرید که ارسال دوم مجاز است یا نه.

با متن و برچسب زمان شروع کنید

پیش از دست زدن به هر چیز دیگر، محتوا را از صفحه کپی کنید، از جمله هر پیش‌نویسی که مرورگر هنوز در فیلد نگه داشته است. زمان، صفحه‌ای که در آن بودید و اقدامی که انجام دادید را بنویسید، زیرا همین سه جزئیات است که بقیه بررسی را ممکن می‌کند. اگر برگه هنوز باز است، آن را باز بگذارید تا ورودی شبکه را بخوانید. ذخیره کردن متن هیچ هزینه‌ای ندارد و از دست دادنش هزینه کل کار است.

سپس دو شکلی از شکست را که واقعاً می‌توانید ببینید از هم جدا کنید. اتصالی که در میانه درخواست قطع شد و سروری که با خطا پاسخ داد در پنل شبکه متفاوت دیده می‌شوند و تنها دومی چیزی درباره تصمیم برنامه به شما می‌گوید.

نتیجه را در نمای خودِ برنامه جست‌وجو کنید

نمای خواندنی را که نتیجه را نشان می‌دهد دوباره بارگذاری کنید: فهرست دیدگاه‌ها، تاریخچه سفارش، صف تیکت یا رکوردی که ویرایش می‌کردید. بر اساس حساب، مقصد، زمان و محتوا تطبیق دهید نه بر اساس آخرین ورودی، چون ممکن است کس دیگری پس از شما نوشته باشد. برای یک کار پس‌زمینه، مرجع موجود و وضعیتش را جست‌وجو کنید نه اینکه برای آزمودن اتصال، عملیات تازه بسازید.

اگر نتیجه آنجاست، کارتان تمام است و خطا به مسیر پاسخ تعلق دارد نه به نوشتن. اگر نیست، احتمال اینکه برنامه هنوز آن را ثبت نکرده باشد را نگه دارید: کاری در صف، نمایی خواندنی با تأخیر یا نسخه‌ای عقب‌مانده می‌تواند مدتی نوشتن موفق را پنهان کند.

پیش از نتیجه‌گیری یک نگاه دوم مشخص به آن بدهید و زمان هر دو بررسی را یادداشت کنید. دو بررسی با فاصله بیست ثانیه شاهد بسیار ضعیف‌تری از دو بررسی با فاصله ده دقیقه است.

تصمیم بگیرید که ارسال دوم بی‌خطر است یا نه

پاسخ به عملیات بستگی دارد، نه به شکیبایی شما. HTTP روش‌هایی را که می‌توان با همان اثر موردنظر تکرار کرد از روش‌هایی که نمی‌توان جدا می‌کند و از تلاش خودکار برای نوع دوم نهی می‌کند، مگر آنکه معلوم باشد معناشناسی اجازه می‌دهد. ساختن دیدگاه، ثبت سفارش و فرستادن پرداخت معمولاً در گروه دوم‌اند، به همین دلیل یک کلیک دوم که موفق به نظر می‌رسد چیزی درباره اولی نمی‌گوید.

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

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

کلید تنها وقتی کمک می‌کند که سرویس آن را در کنار عملیات ذخیره کند و در تکرار، نتیجه اصلی را برگرداند. این رفتار را پیش از تکیه بر آن در محیط عملیاتی، روی یک نقطه پایانی آزمایشی بیازمایید.

پیش از هر فشردن دوباره، شواهد را جمع کنید

ورودی شبکه را نگه دارید نه تصویر صفحه از خطا را. روش درخواست، URL، پاسخ یا پایان مهلت و زمانی که رخ داده، همان چیزی است که مدیر می‌تواند با سوابق برنامه تطبیق دهد. ورودی را تنها در صورتی به‌صورت فرمان صادر یا کپی کنید که سپس کوکی‌ها، سرآیندهای احراز هویت و هر محتوای خصوصی را از نسخه حذف کنید. نشست خودتان را دست‌نخورده بگذارید و هرگز درخواست ضبط‌شده‌ای را که اعتبارنامه دارد به‌عنوان میان‌بر بازپخش نکنید.

از مالک سرویس یک پرسش مشخص بپرسید: آیا عملیات با این محتوا در این زمان موفق شد و مرجعی برای آن هست؟ این پرسش پاسخ دارد، در حالی که "آیا سایت خراب شد" پاسخ ندارد.

هدف این تمرین اثبات این است که اقدام دقیقاً یک بار انجام شده. پیام خطایی که می‌توانید ردش کنید با رکوردی که می‌توانید به آن اعتماد کنید یکی نیست و پیش از ارسال هر چیز دیگر به دومی نیاز دارید.