সময় শেষ হওয়া ওই সাবমিট কি সত্যিই আপনার কাজ সংরক্ষণ করেছে?

বোতামটি ঘুরছে, ট্যাবে একটি ত্রুটি দেখাচ্ছে, আর যে ফর্মটি ভরতে আপনার দশ মিনিট লেগেছিল সেটি চলে গেছে। আপনি জানেন না সংযোগ বিচ্ছিন্ন হওয়ার আগে লেখাটি পৌঁছেছিল কি না। এই অজানাকে ব্যর্থতা হিসেবে ধরে নিলেই ডুপ্লিকেট মন্তব্য, দ্বিগুণ অর্ডার আর বারবার পাঠানো সাপোর্ট টিকিট তৈরি হয়।

একটি নির্দিষ্ট ক্রমে উদ্ধার করুন: লেখাটি ধরে রাখুন, ফলাফল খুঁজুন, আর কেবল তারপরেই ঠিক করুন দ্বিতীয় সাবমিট অনুমোদিত কি না।

লেখা ও সময়ের চিহ্ন দিয়ে শুরু করুন

অন্য কিছুতে হাত দেওয়ার আগে পৃষ্ঠা থেকে বিষয়বস্তু কপি করুন, ব্রাউজার যে খসড়া এখনো ফিল্ডে রেখেছে সেটিও সহ। সময়, আপনি যে পৃষ্ঠায় ছিলেন এবং যে কাজটি করেছিলেন তা লিখে রাখুন, কারণ এই তিনটি বিবরণই বাকি তদন্ত সম্ভব করে। ট্যাবটি এখনো খোলা থাকলে নেটওয়ার্ক এন্ট্রি পড়া পর্যন্ত সেটি খোলা রাখুন। লেখা সংরক্ষণে কিছুই খরচ হয় না, আর তা হারালে পুরো কাজটিই হারায়।

তারপর আপনি সত্যিই দেখতে পাওয়া দুই ধরনের ব্যর্থতাকে আলাদা করুন। অনুরোধের মাঝপথে ছিঁড়ে যাওয়া সংযোগ আর ত্রুটি দিয়ে উত্তর দেওয়া সার্ভার নেটওয়ার্ক প্যানেলে আলাদা দেখায়, এবং কেবল দ্বিতীয়টিই অ্যাপের সিদ্ধান্ত সম্পর্কে কিছু বলে।

অ্যাপের নিজস্ব দৃশ্যে ফলাফল খুঁজুন

যে পড়ার দৃশ্যটি ফলাফল দেখাবে সেটি রিলোড করুন: মন্তব্যের তালিকা, অর্ডারের ইতিহাস, টিকিটের সারি বা আপনি যে রেকর্ডটি সম্পাদনা করছিলেন। সবচেয়ে সাম্প্রতিক এন্ট্রির বদলে অ্যাকাউন্ট, গন্তব্য, সময় ও বিষয়বস্তু মিলিয়ে দেখুন, কারণ আপনার পরে অন্য কেউ লিখে থাকতে পারে। ব্যাকগ্রাউন্ড কাজের ক্ষেত্রে সংযোগ পরীক্ষা হিসেবে নতুন অপারেশন তৈরি না করে বিদ্যমান রেফারেন্স ও তার অবস্থা খুঁজুন।

ফলাফল যদি সেখানে থাকে, আপনার কাজ শেষ এবং ত্রুটিটি লেখার পথের নয়, উত্তরের পথের। যদি না থাকে, তবে অ্যাপটি এখনো এটি নিশ্চিত করেনি এমন সম্ভাবনা ধরে রাখুন: সারিতে থাকা কাজ, বিলম্বিত পড়ার দৃশ্য বা পিছিয়ে থাকা রেপ্লিকা কিছুক্ষণ সফল লেখা লুকিয়ে রাখতে পারে।

সিদ্ধান্তে পৌঁছানোর আগে এটিকে একটি নির্দিষ্ট দ্বিতীয়বার দেখুন, এবং দুটি যাচাইয়ের সময় লিখে রাখুন। কুড়ি সেকেন্ড ব্যবধানে দুটি যাচাই দশ মিনিট ব্যবধানের দুটি যাচাইয়ের চেয়ে অনেক দুর্বল প্রমাণ।

দ্বিতীয় সাবমিট নিরাপদ কি না ঠিক করুন

উত্তরটি আপনার ধৈর্যের ওপর নয়, অপারেশনের ওপর নির্ভর করে। 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, উত্তর বা টাইমআউট এবং তা যে সময়ে ঘটেছে সেগুলোই প্রশাসক অ্যাপ্লিকেশনের রেকর্ডের সঙ্গে মিলাতে পারেন। এন্ট্রিটি কমান্ড হিসেবে রপ্তানি বা কপি করুন কেবল যদি এরপর কপি থেকে কুকি, অনুমোদন হেডার ও যেকোনো ব্যক্তিগত বিষয়বস্তু সরিয়ে দেন। নিজের সেশন অক্ষত রাখুন, এবং ধরা পড়া শংসাপত্রসহ অনুরোধ কখনোই শর্টকাট হিসেবে পুনরায় চালাবেন না।

সেবার মালিককে একটি নির্দিষ্ট প্রশ্ন করুন: এই বিষয়বস্তু দিয়ে এই সময়ে অপারেশনটি সফল হয়েছিল কি, এবং এর কোনো রেফারেন্স আছে কি? এই প্রশ্নের উত্তর আছে, কিন্তু "সাইটটি কি নষ্ট হয়েছে" প্রশ্নের উত্তর নেই।

এই অনুশীলনের উদ্দেশ্য হলো কাজটি ঠিক একবারই ঘটেছে তা প্রতিষ্ঠা করা। যে ত্রুটি-বার্তা আপনি বন্ধ করতে পারেন তা যে রেকর্ড আপনি বিশ্বাস করতে পারেন তার সমান নয়, আর আরও কিছু পাঠানোর আগে আপনার দরকার দ্বিতীয়টি।