मैं एक ही SMS दो बार भेजने से कैसे बचूँ?

हो सकता है कि Bird किसी SMS को स्वीकार कर ले, पर आपके एप्लिकेशन तक प्रतिक्रिया पहुँचने से पहले कनेक्शन टूट जाए। नई कुंजी के साथ फिर से प्रयास करने पर संदेश दूसरी बार भेजा जा सकता है, क्योंकि Bird इसे अलग अनुरोध मानता है।

कुंजी कैसे काम करती है?

आप हर इच्छित SMS भेजने के लिए एक Idempotency-Key हेडर सेट करते हैं और उसी अनुरोध के लिए फिर से प्रयास करते समय उसी हेडर का दोबारा उपयोग करते हैं। जब Bird मूल प्रतिक्रिया को सहेज कर रखता है, तो मेल खाने वाला फिर से प्रयास भेजने की प्रक्रिया को दोबारा चलाए बिना वही प्रतिक्रिया लौटाता है।

उदाहरण के लिए, किसी ऑर्डर की पुष्टि में टाइमआउट और उसके बाद के फिर से प्रयास, दोनों में एक ही कुंजी रहती है। किसी दूसरे ऑर्डर की पुष्टि को अलग कुंजी मिलती है।

दोहराई गई प्रतिक्रियाओं में Idempotency-Replay: true शामिल होता है, जिससे आपके लॉग में दोहराई गई प्रतिक्रिया और नए सिरे से संसाधित अनुरोध को अलग पहचाना जा सकता है।

SMS कुंजियाँ आपके वर्कस्पेस तक सीमित होती हैं। Bird अपने idempotency अनुबंध के तहत पूरी हुई प्रतिक्रियाओं को तीन घंटे तक सहेज कर रखता है। इस अवधि के बाद वही कुंजी नया अनुरोध चला सकती है, क्योंकि उसका दोहराव रिकॉर्ड समाप्त हो चुका होता है। इसलिए एक दिन बाद फिर से प्रयास करने से पहले आपको मूल परिणाम का मिलान करना होगा, तभी दोबारा भेजें।

विफलता वाली प्रतिक्रियाएँ मुझे क्या बताती हैं?

त्रुटि कोड बताता है कि अनुरोध बदला गया है, अनुरोध अभी पूरा नहीं हुआ है, या सुरक्षा उपलब्ध नहीं है।

• 409 के साथ E01005 IdempotencyKeyReuse: एक ही कुंजी किसी दूसरे अनुरोध के लिए उपयोग की गई। फिर से प्रयास करने से पहले कुंजी निर्धारण ठीक करें, क्योंकि यह कुंजी मूल अनुरोध की है। Bird मेथड, एंडपॉइंट, पाथ और क्वेरी पैरामीटर, और रॉ बॉडी की तुलना करता है। JSON में व्हाइटस्पेस का छोटा सा बदलाव भी अनुरोध को अलग बना देता है।
• 409 के साथ E01004 RequestInProgress: उसी कुंजी वाला एक समवर्ती अनुरोध अभी पूरा नहीं हुआ है। थोड़ा रुकें और उसी कुंजी और अनुरोध के साथ फिर से प्रयास करें, ताकि मूल अनुरोध पूरा हो सके। चालू अनुरोध का लॉक 30 सेकंड के भीतर समाप्त हो जाता है। लॉक समाप्त होने से यह तय नहीं होता कि मूल भेजना प्रभावी हुआ या नहीं।
• 503 के साथ E01033 IdempotencyUnavailable: चलने से पहले सुरक्षा उपलब्ध नहीं थी, इसलिए यह प्रयास नहीं चला। उसी कुंजी और अनुरोध के साथ बैकऑफ़ का उपयोग करते हुए फिर से प्रयास करें। यह प्रतिक्रिया किसी पिछले प्रयास का परिणाम तय नहीं करती।
• अन्य 5xx प्रतिक्रियाएँ या टाइमआउट: उसी कुंजी और अनुरोध के साथ बैकऑफ़ का उपयोग करते हुए फिर से प्रयास करें। Bird 5xx प्रतिक्रियाओं को सहेज कर नहीं रखता। फिर से प्रयास करने पर सहेजी गई सफल प्रतिक्रिया लौटती है, या कोई प्रतिक्रिया सहेजी न गई हो तो भेजना दोबारा चल सकता है।

idempotency हेडर इन फिर से प्रयासों के दौरान अनुरोध की पहचान बनाए रखता है।

क्या कुंजी डुप्लिकेट न होने की गारंटी देती है?

कुंजी डुप्लिकेट भेजने की संभावना घटाती है, लेकिन यह गारंटी नहीं देती कि भेजना केवल एक बार ही निष्पादित होगा।

Bird के प्रतिक्रिया सहेजने से पहले ही भेजना प्रभावी हो सकता है। अगर प्रतिक्रिया सहेजना विफल हो जाए या प्रगति में चल रहे अनुरोध का लॉक समाप्त हो जाए, तो फिर से प्रयास करने पर भेजना दोबारा निष्पादित हो सकता है। तीन घंटे की सहेजने की अवधि भी रीप्ले सुरक्षा को सीमित करती है।

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

अगर हैंडसेट कोई संदेश दो बार दिखाए तो क्या करें?

आइडेम्पोटेंसी कुंजी API के फिर से प्रयासों को नियंत्रित करती है; यह तय नहीं करती कि प्राप्तकर्ता का फ़ोन संदेश कैसे दिखाता है। केवल एक स्क्रीनशॉट से यह स्थापित नहीं होता कि डुप्लिकेट कहाँ से उत्पन्न हुआ।

एप्लिकेशन के पूरे भेजने के लॉग की तुलना Bird के संदेश रिकॉर्ड से करें। कई स्वीकृत संदेश ID से कई बार भेजना स्थापित हो सकता है। अधूरे लॉग में केवल एक ID मिलने से यह साबित नहीं होता कि डुप्लिकेट आगे के नेटवर्क में हुआ। सपोर्ट से जाँच करने का अनुरोध करते समय संबंधित ID, गंतव्य और टाइमस्टैम्प शामिल करें।

मुझे क्या करना चाहिए?

1. हर इच्छित SMS भेजने के लिए एक कुंजी निर्धारित करें और उसके फिर से प्रयासों के लिए वही समान अनुरोध दोबारा उपयोग करें।
2. नेटवर्क त्रुटियों, टाइमआउट और 5xx प्रतिक्रियाओं के लिए बैकऑफ़ के साथ फिर से प्रयास करें, और उपलब्ध रीप्ले सुरक्षा बनाए रखने के लिए कुंजी वही रखें।
3. बदले हुए अनुरोध से होने वाले टकराव ठीक करें, और जब मूल अनुरोध अभी भी प्रगति में हो तो फिर से प्रयास करने में देरी करें।
4. अनिश्चित भेजने का मिलान करें, जिनमें तीन घंटे की रीप्ले अवधि के बाद वाले भी शामिल हैं, और उसके बाद ही तय करें कि दोबारा भेजना उचित है या नहीं।