वेळ संपलेल्या त्या सबमिटने खरोखर तुमचे काम जतन केले का?

बटण फिरत आहे, टॅब त्रुटी दाखवत आहे, आणि दहा मिनिटे भरलेला फॉर्म गायब झाला आहे. तुम्हाला माहीत नाही की जोडणी तुटण्यापूर्वी लेखन पोहोचले का. या अनोळखी गोष्टीकडे अपयश म्हणून पाहणे हेच नक्कल टिप्पण्या, दुहेरी ऑर्डर आणि वारंवार येणारी सहाय्य तिकिटे तयार करते.

ठरलेल्या क्रमाने पुनर्प्राप्ती करा: मजकूर ठेवा, निकाल शोधा, आणि त्यानंतरच दुसरे सबमिट मान्य आहे का ते ठरवा.

मजकूर आणि वेळेच्या शिक्क्यापासून सुरुवात करा

इतर काहीही हात लावण्यापूर्वी पानावरून सामग्री कॉपी करा, ब्राउझर अजूनही फील्डमध्ये ठेवलेला मसुदाही. वेळ, तुम्ही होता ते पान आणि केलेली क्रिया लिहून ठेवा, कारण हे तीन तपशीलच उर्वरित तपासणी शक्य करतात. टॅब अजून उघडा असल्यास, नेटवर्क नोंद वाचेपर्यंत तो उघडा ठेवा. मजकूर जतन करण्यास काही खर्च नाही, आणि तो गमावण्यास संपूर्ण कामाचा खर्च येतो.

मग तुम्ही खरोखर निरीक्षण करू शकता अशा दोन प्रकारच्या बिघाडांचे वेगळे करा. विनंतीच्या मध्ये तुटलेली जोडणी आणि त्रुटीने उत्तर दिलेला सर्व्हर नेटवर्क पॅनलमध्ये वेगळे दिसतात, आणि ॲपच्या निर्णयाबद्दल काही सांगतो तो दुसरा एकटाच.

ॲपच्याच दृश्यात निकाल शोधा

निकाल दाखवणारे वाचन दृश्य पुन्हा लोड करा: टिप्पण्यांची यादी, ऑर्डर इतिहास, तिकिटांची रांग किंवा तुम्ही संपादित करत असलेली नोंद. सर्वात नवीन नोंदीऐवजी खाते, गंतव्य, वेळ आणि सामग्रीनुसार जुळवा, कारण तुमच्यानंतर दुसऱ्या कोणी लिहिले असू शकते. पार्श्वभूमी कामासाठी, कनेक्टिव्हिटी चाचणी म्हणून नवीन क्रिया तयार करण्याऐवजी विद्यमान संदर्भ आणि त्याची स्थिती शोधा.

निकाल तिथे असल्यास, तुमचे काम पूर्ण आणि त्रुटी लेखनाची नाही, उत्तराच्या मार्गाची आहे. नसल्यास, ॲपने ती अजून निश्चित केली नसल्याची शक्यता ठेवा: रांगेतील काम, उशिरा येणारे वाचन दृश्य किंवा मागे राहिलेली प्रत यशस्वी लेखन काही काळ लपवू शकतात.

निष्कर्ष काढण्यापूर्वी त्याला ठरलेला दुसरा दृष्टिक्षेप द्या, आणि दोन्ही तपासण्यांची वेळ लिहा. वीस सेकंदांच्या अंतराने केलेल्या दोन तपासण्या दहा मिनिटांच्या अंतराने केलेल्या दोन तपासण्यांपेक्षा खूप कमकुवत पुरावा आहेत.

दुसरे सबमिट सुरक्षित आहे का ते ठरवा

उत्तर क्रियेवर अवलंबून आहे, तुमच्या संयमावर नाही. 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, उत्तर किंवा कालबाह्यता आणि ते कधी घडले हेच व्यवस्थापकाला ॲपच्या नोंदींशी जुळवता येते. नोंद आदेश म्हणून निर्यात किंवा कॉपी करा, तरच नंतर प्रतमधून कुकीज, अधिकृतता शीर्षलेख आणि कोणतीही खाजगी सामग्री काढून टाका. तुमचे स्वतःचे सत्र अभंग ठेवा, आणि पकडलेली ओळखपत्रे असलेली विनंती कधीही शॉर्टकट म्हणून पुन्हा चालवू नका.

सेवेच्या मालकाला एक ठोस प्रश्न विचारा: या सामग्रीसह या वेळी क्रिया यशस्वी झाली का, आणि तिचा संदर्भ आहे का? या प्रश्नाचे उत्तर आहे, पण "साइट तुटली का" याचे उत्तर नाही.

या सरावाचा उद्देश क्रिया नेमकी एकदाच घडली हे स्थापित करणे आहे. तुम्ही बंद करू शकता अशी त्रुटी-संदेश ही तुम्ही विश्वास ठेवू शकता अशा नोंदीसारखी नाही, आणि दुसरेच तुम्हाला आणखी काही पाठवण्यापूर्वी लागते.