क्या वह समय-समाप्त सबमिट वाकई आपका काम सहेज पाया?

बटन घूम रहा है, टैब त्रुटि दिखा रहा है, और वह फ़ॉर्म गायब है जिसे भरने में आपने दस मिनट लगाए। आप नहीं जानते कि कनेक्शन मरने से पहले लिखावट पहुँची या नहीं। इस अनजान को विफलता मान लेना ही डुप्लिकेट टिप्पणियाँ, दोहरे ऑर्डर और बार-बार आने वाले सहायता टिकट पैदा करता है।

एक तय क्रम में सुधारें: टेक्स्ट रखें, नतीजा खोजें, और उसके बाद ही तय करें कि दूसरा सबमिट मान्य है या नहीं।

टेक्स्ट और समय-चिह्न से शुरू करें

किसी और चीज़ को छूने से पहले पेज से सामग्री कॉपी कर लें, जिसमें वह मसौदा भी शामिल है जो ब्राउज़र अभी भी फ़ील्ड में रखे हुए है। समय, आप जिस पेज पर थे और आपने जो क्रिया की, लिख लें, क्योंकि यही तीन विवरण बाकी जाँच को संभव बनाते हैं। अगर टैब अभी खुला है, तो नेटवर्क प्रविष्टि पढ़ने तक उसे खुला रहने दें। टेक्स्ट सहेजने का कोई खर्च नहीं है और उसे खोने का खर्च पूरा काम है।

फिर उन दो तरह की विफलताओं को अलग करें जिन्हें आप वास्तव में देख सकते हैं। अनुरोध के बीच में टूटा कनेक्शन और त्रुटि के साथ जवाब देने वाला सर्वर नेटवर्क पैनल में अलग दिखते हैं, और केवल दूसरा ही ऐप के फ़ैसले के बारे में कुछ बताता है।

ऐप के अपने दृश्य में नतीजा खोजें

वह पठन दृश्य फिर से लोड करें जो नतीजा दिखाएगा: टिप्पणियों की सूची, ऑर्डर का इतिहास, टिकट की कतार या वह रिकॉर्ड जिसे आप संपादित कर रहे थे। सबसे नई प्रविष्टि के बजाय खाते, गंतव्य, समय और सामग्री से मिलान करें, क्योंकि कोई और आपके बाद लिख सकता है। पृष्ठभूमि कार्य के लिए, कनेक्टिविटी परीक्षण के रूप में नया ऑपरेशन बनाने के बजाय मौजूदा संदर्भ और उसकी स्थिति खोजें।

अगर नतीजा वहाँ है, तो आपका काम पूरा और त्रुटि लिखावट की नहीं, जवाब के रास्ते की है। अगर वह नहीं है, तो यह संभावना रखें कि ऐप ने उसे अभी दर्ज नहीं किया: कतार में पड़ा कार्य, विलंबित पठन दृश्य या पीछे रह गई प्रतिकृति कुछ समय के लिए सफल लिखावट छिपा सकती है।

नतीजा निकालने से पहले उसे एक तय दूसरी नज़र दें, और दोनों जाँचों का समय लिखें। बीस सेकंड के अंतर से की गई दो जाँचें दस मिनट के अंतर से की गई दो जाँचों से कहीं कमज़ोर सबूत हैं।

तय करें कि दूसरा सबमिट सुरक्षित है या नहीं

जवाब ऑपरेशन पर निर्भर है, आपके धैर्य पर नहीं। 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, जवाब या समय-सीमा और वह कब हुआ, यही वह चीज़ है जिसे व्यवस्थापक ऐप के रिकॉर्ड से मिला सकता है। प्रविष्टि को आदेश के रूप में केवल तभी निर्यात या कॉपी करें जब आप उसके बाद कॉपी से कुकीज़, प्राधिकरण हेडर और कोई भी निजी सामग्री हटा दें। अपना सत्र अक्षुण्ण रखें, और पकड़े गए क्रेडेंशियल वाले अनुरोध को कभी भी शॉर्टकट के रूप में दोबारा न चलाएँ।

सेवा के मालिक से एक ठोस सवाल पूछें: इस सामग्री के साथ इस समय ऑपरेशन सफल हुआ, और क्या उसका कोई संदर्भ है? इस सवाल का जवाब है, जबकि "क्या साइट टूट गई" का जवाब नहीं है।

इस अभ्यास का उद्देश्य यह स्थापित करना है कि क्रिया ठीक एक बार हुई। जिस त्रुटि-संदेश को आप हटा सकते हैं, वह उस रिकॉर्ड के समान नहीं है जिस पर आप भरोसा कर सकते हैं, और दूसरा ही वह चीज़ है जो आपको कुछ और भेजने से पहले चाहिए।