कनेक्शन टूटने पर आपको पता नहीं चल पाता कि भेजने का अनुरोध सफल हुआ या नहीं। पुष्टि खो जाने पर वेबहुक भेजने वाला ऐसा इवेंट भी दोबारा डिलीवर कर सकता है जिसे आपका ऐप्लिकेशन पहले ही सहेज चुका है।
ये विफलताएँ विपरीत दिशाओं में होती हैं। Bird आपकी दी गई कुंजी से दोहराए गए API अनुरोध को पहचान सकता है। आपके वेबहुक रिसीवर को स्वीकार किए गए इवेंट का अपना रिकॉर्ड रखना होता है।
मैं भेजने के अनुरोध को सुरक्षित रूप से फिर से प्रयास कैसे करूँ?
हर फिर से प्रयास के लिए वही Idempotency-Key और बिल्कुल वही अनुरोध दोबारा इस्तेमाल करें। गारंटी ठीक एक बार स्वीकार करने की है: तीन घंटे के भीतर मेल खाते फिर से प्रयास एक ही स्वीकार किए गए ऑपरेशन में बदलने चाहिए, भले ही उसकी प्रतिक्रिया आपसे खो गई हो।
कुंजी आप चुनते हैं, जो अधिकतम 255 अक्षरों की हो सकती है, और फिर से प्रयास करते समय उसे बनाए रखते हैं। welcome-user/usr_abc123 जैसा स्थिर मान आपकी प्रोसेस के दोबारा शुरू होने के बाद भी एक welcome-message ऑपरेशन की पहचान कर सकता है।
यह हेडर POST, PATCH और DELETE जैसे बदलाव करने वाले अनुरोधों पर लागू होता है। बिना कुंजी वाले अनुरोध को इस डुप्लिकेट-रोकथाम के बिना प्रोसेस किया जाता है। GET इस हेडर को अनदेखा करता है, क्योंकि रिसोर्स पढ़ना पहले से ही दोहराने के लिए सुरक्षित है।
मेल खाते पूरे हो चुके अनुरोध के लिए Bird संग्रहीत प्रतिक्रिया लौटाता है, जिसमें उसका मूल स्टेटस और बॉडी शामिल होते हैं। प्रतिक्रिया में Idempotency-Replay: true होता है, ताकि आप अपने लॉग में इस दोबारा उपयोग को पहचान सकें।
आइडेम्पोटेंसी गाइड के अनुसार पूरी हो चुकी प्रतिक्रिया की अवधि डिफ़ॉल्ट रूप से तीन घंटे है। यह अवधि समाप्त होने के बाद किया गया फिर से प्रयास नए ऑपरेशन के रूप में चल सकता है। डुप्लिकेट भेजने को हमेशा रोकने के लिए उस कुंजी पर निर्भर न रहें।
Bird SDK किसी बदलाव वाले अनुरोध के लिए कुंजी बनाते हैं और अपने आंतरिक फिर से प्रयासों में उसे दोबारा इस्तेमाल करते हैं। Bird CLI भी कुंजी न होने पर बदलाव वाले अनुरोध के लिए कुंजी बनाता है। जब अलग-अलग कमांड रन को एक ही ऑपरेशन साझा करना हो, तो --idempotency-key स्पष्ट रूप से सेट करें।
SMTP सबमिशन के लिए X-Bird-Idempotency-Key मैसेज हेडर इस्तेमाल करें। इससे फिर से प्रयास किया गया सबमिशन उसी ऑपरेशन की पहचान कर पाता है।
अगर मैं कुंजी गलत तरीके से दोबारा इस्तेमाल करूँ तो क्या होता है?
Bird किसी दूसरे ऑपरेशन की प्रतिक्रिया लौटाने के बजाय कुंजी के टकराव वाले उपयोग को अस्वीकार करता है।
| स्थिति | प्रतिक्रिया और समाधान |
|---|---|
| वही कुंजी और वही अनुरोध, प्रतिक्रिया सहेजी हुई | सहेजने की अवधि के भीतर संग्रहीत प्रतिक्रिया, Idempotency-Replay: true के साथ। |
| पूरी हो चुकी कुंजी किसी अलग अनुरोध के लिए दोबारा इस्तेमाल की गई | E01005 के साथ 409, यानी आइडेम्पोटेंसी कुंजी का दोबारा इस्तेमाल। फिर से प्रयास करने से पहले कुंजी ठीक करें। |
| उसी कुंजी वाला दूसरा अनुरोध अभी चल रहा है | E01004 के साथ 409, यानी अनुरोध प्रगति में है। थोड़ी देर रुकें और फिर से प्रयास करें। |
| कुंजी 255 अक्षरों से लंबी है | इस हेडर को घोषित करने वाले एंडपॉइंट पर E01001 के साथ 422। कुंजी छोटी करें। |
तुलना में मेथड, एंडपॉइंट, पाथ पैरामीटर, क्वेरी स्ट्रिंग और बॉडी शामिल होते हैं। JSON के लिए व्हाइटस्पेस बदलने से अनुरोध की पहचान बदल जाती है, इसलिए फिर से प्रयास करते समय मूल बॉडी को बिना बदले रखें।
अगर मूल अनुरोध अभी चल रहा है, तो फिर से प्रयास करने से पहले रुकें। वही कुंजी और वही अनुरोध रखें, ताकि फिर से प्रयास मूल ऑपरेशन की पहचान करे।
API किसी 5xx प्रतिक्रिया को पूरी हो चुकी प्रतिक्रिया के रूप में नहीं सहेजता। टाइमआउट या सर्वर त्रुटि होने पर तीन घंटे के भीतर सीमित बैकऑफ़, उसी कुंजी और बिल्कुल वही अनुरोध के साथ फिर से प्रयास करें। ठीक एक बार स्वीकार करने की गारंटी खोई हुई प्रतिक्रिया पर भी लागू होती है।
4xx अस्वीकृति सहेजी जा सकती है। सुधारे गए अनुरोध के लिए नई कुंजी इस्तेमाल करें: बिना बदलाव का फिर से प्रयास सहेजी गई अस्वीकृति को दोबारा लौटाता है, और बदला हुआ इनपुट उस सहेजी गई कुंजी से टकराता है।
मुझे एक ही वेबहुक दो बार क्यों मिलता है?
अगर Bird को सफल प्रतिक्रिया नहीं मिलती, तो वह ऐसे इवेंट को फिर से भेजने का प्रयास कर सकता है जिसे आपका रिसीवर पहले ही सहेज चुका है।
रिसीवर कनेक्शन टूटने से ठीक पहले किसी इवेंट को सहेज सकता है। Bird को कोई सफल पावती नहीं दिखती, इसलिए वह फिर से प्रयास करता है, भले ही रिसीवर के पास इवेंट पहले से हो।
हर फिर से प्रयास में वही webhook-id हेडर रहता है, जो इवेंट की पहचान करता है। विफल डिलीवरी को दोबारा चलाने पर भी यही पहचानकर्ता रहता है, इसलिए दोनों को एक ही इवेंट के रूप में पहचाना जा सकता है।
मैं अपने हैंडलर को आइडेम्पोटेंट कैसे बनाऊँ?
इवेंट का काम शेड्यूल करने से पहले हर webhook-id को यूनिक डेटाबेस कंस्ट्रेंट के साथ सहेजें।
इन्सर्ट करने से पहले मौजूदा पंक्ति की जाँच करने पर रेस की स्थिति बनती है: दो समवर्ती अनुरोधों को एक साथ कोई पंक्ति न दिखे, ऐसा हो सकता है। डुप्लिकेट पहचानकर्ताओं को डेटाबेस से अस्वीकार करवाएँ।
पहचानकर्ता और जॉब को एक ही ट्रांज़ैक्शन में सहेजें। इससे ऐसा नहीं होगा कि पहचानकर्ता दर्ज हो जाए पर कोई काम कतार में न जुड़े।
- अनुरोध को सत्यापित करें, फिर उसके पहचानकर्ता और जॉब को एक ही ट्रांज़ैक्शन में इन्सर्ट करें।
- वह ट्रांज़ैक्शन कमिट होने के बाद
2xxलौटाएँ, ताकि Bird फिर से प्रयास करना बंद कर सके। - सहेजे गए जॉब को ऐसे वर्कर में प्रोसेस करें जो अपनी कार्रवाइयों को सुरक्षित रूप से दोहरा सके।
यदि कोई डुप्लिकेट पहचानकर्ता पहले से कमिट हो चुका है, तो कोई नया जॉब बनाए बिना सफलता लौटाएँ। यदि ट्रांज़ैक्शन विफल हो जाए, तो त्रुटि लौटाएँ ताकि Bird फिर से प्रयास करे।
धीमे काम को रिसीवर से बाहर रखें, क्योंकि उसकी प्रतीक्षा करने से अनुरोध का टाइमआउट हो सकता है। वर्कर वेबहुक डिलीवरी से असंबंधित कारणों से भी फिर से प्रयास कर सकता है, इसलिए केवल रिसीवर को सुरक्षित करना पर्याप्त नहीं है।
इवेंट क्रम से बाहर भी पहुँच सकते हैं। नई स्थिति को ओवरराइट करने से पहले timestamp में इवेंट के समय की तुलना करें। विफल वेबहुक के फिर से प्रयास में आंशिक लागत वाला उदाहरण दिया गया है।
मुझे किन बातों पर निर्भर नहीं रहना चाहिए?
यह न मानें कि अनुरोधों के डुप्लिकेशन हटाने से डुप्लिकेट दुष्प्रभाव असंभव हो जाते हैं।
किसी समर्थित HTTP राइट के लिए Bird आइडेम्पोटेंसी कुंजी को अनुरोध के वर्कस्पेस या संगठन से जोड़ता है। समर्थित स्टाफ़ ऑपरेशन इसके बजाय कार्रवाई करने वाले स्टाफ़ खाते का उपयोग करते हैं। अगर सुरक्षा उपलब्ध नहीं है, तो Bird उस प्रयास को चलाने से पहले 503 E01033 IdempotencyUnavailable लौटाता है। इससे किसी पिछले प्रयास का परिणाम तय नहीं होता। एक बार ही स्वीकार करने की गारंटी तीन घंटे के भीतर मेल खाते फिर से प्रयासों पर लागू होती है। डिलीवरी की पुष्टि के लिए मैसेज का स्टेटस जाँचें। अगर फिर से प्रयास खत्म हो जाएँ या अवधि समाप्त हो जाए, तो दोबारा सबमिट करने से पहले मूल ऑपरेशन का परिणाम जाँचें।
इसी तरह, webhook-id एक ही इवेंट की बार-बार होने वाली डिलीवरी को अलग पहचानता है। अलग-अलग इवेंट के पहचानकर्ता अलग होते हैं। इन इवेंट के लिए एक ही कार्रवाई दोहराना उचित है या नहीं, यह फिर भी आपका एप्लिकेशन तय करता है।
आइडेम्पोटेंसी में API के फिर से प्रयास का व्यवहार बताया गया है। वेबहुक में वे अलग डिलीवरी गारंटियाँ बताई गई हैं जिन्हें आपका रिसीवर संभालता है।
संक्षेप में
API के लिए फिर से प्रयास और वेबहुक के फिर से प्रयास के लिए अलग-अलग रिकॉर्ड चाहिए।
Bird को भेजे गए अनुरोध के लिए Idempotency-Key दोबारा इस्तेमाल करें। आपका रिसीवर webhook-id सहेजता है ताकि वह पहले से स्वीकार किए गए इवेंट को पहचान सके।
अस्वीकृतियाँ भी सहेजी जा सकती हैं।
सहेजी गई अस्वीकृति दोबारा लौटाई जाती है। सुधारे गए अनुरोध के लिए नई कुंजी चाहिए, क्योंकि उसका इनपुट अलग है।
पूरी हो चुकी कुंजी अलग-अलग अनुरोधों की पहचान नहीं कर सकती।
JSON का बॉडी या एंडपॉइंट बदलने पर 409 कॉन्फ़्लिक्ट मिल सकता है। उसी कॉन्फ़्लिक्ट के लिए बिना बदलाव फिर से प्रयास करने के बजाय कुंजी ठीक करें।
डुप्लिकेशन रोकने की सीमाएँ हैं।
API की गारंटी तीन घंटे के भीतर मेल खाते फिर से प्रयासों को ठीक एक बार स्वीकार करने तक सीमित है। आपके वेबहुक रिसीवर को इवेंट के अपने स्थायी रिकॉर्ड चाहिए।