विफल वेबहुक के लिए फिर से प्रयास कैसे किया जाता है, और क्या इवेंट क्रम में पहुँचते हैं?

आपका रिसीवर किसी इवेंट को सहेज सकता है, भले ही भेजने वाले को उसकी पुष्टि कभी न मिले। इसलिए फिर से प्रयास करने पर वह काम दोहराया जा सकता है जिसे आपका ऐप्लिकेशन पहले ही स्वीकार कर चुका है।

फिर से प्रयास करने से कुछ इवेंट देर से पहुँचते हैं। उन फिर से प्रयासों के पूरे होने से पहले ही नए इवेंट पहुँच सकते हैं। इवेंट पहचानकर्ता और घटित होने का समय सहेजें, ताकि ये डिलीवरी नए काम को ओवरराइट न कर सकें।

किसे विफल डिलीवरी माना जाता है?

जब Bird को असफलता वाली प्रतिक्रिया मिलती है या अनुरोध का समय समाप्त हो जाता है, तो वह डिलीवरी को विफल मानता है।

इवेंट सहेजने के बाद HTTP 2xx लौटाएँ, ताकि उस डिलीवरी के लिए फिर से प्रयास रुक जाएँ। रीडायरेक्ट, क्लाइंट त्रुटि या सर्वर त्रुटि मिलने पर डिलीवरी फिर से प्रयास के योग्य बनी रहती है।

उदाहरण के लिए, 400 अस्वीकृत अनुरोध को दर्ज करता है, लेकिन Bird को उसे छोड़ देने के लिए नहीं कहता। जब सिग्नेचर सत्यापन या स्थायी स्टोरेज विफल हो, तो त्रुटि प्रतिक्रिया लौटाएँ, ताकि डिलीवरी को बाद में रिकवर किया जा सके।

इवेंट की पुष्टि करने से पहले उसे सहेजें। अगर आप पहले सफलता लौटाते हैं और बाद में स्टोरेज विफल हो जाता है, तो इवेंट खो सकता है।

धीमी प्रोसेसिंग को बैकग्राउंड वर्कर में रखें, ताकि आपका रिसीवर तुरंत जवाब दे सके। उस काम के शुरू होने से पहले इवेंट का सत्यापन करना और उसे सुरक्षित रखना रिसीवर का काम है।

फिर से प्रयास का शेड्यूल क्या है?

Bird पहले प्रयास के बाद फिर से प्रयास के लिए सात अंतराल इस्तेमाल करता है, यानी कुल आठ प्रयास होते हैं।

स्वचालित प्रयास खत्म होने से पहले, इस शेड्यूल से आपको रिसीवर ठीक करने के लिए लगभग 27.5 घंटे मिलते हैं।

आउटेज के बाद फिर से प्रयासों को फैलाने के लिए Bird हर प्रतीक्षा को किसी भी दिशा में 20 प्रतिशत तक यादृच्छिक रूप से बदलता है। इसलिए अन्य समायोजनों से पहले, पाँच मिनट की देरी चार से छह मिनट के बीच होती है।

थ्रॉटलिंग प्रतिक्रिया या टाइमआउट अगली प्रतीक्षा को बदल सकता है। Bird Retry-After को भी ध्यान में रखता है, जो एक प्रतिक्रिया हेडर है और अगले प्रयास से पहले देरी का अनुरोध करता है। Bird इस देरी को सेकंड की संख्या या HTTP तारीख के रूप में स्वीकार करता है। अगर अनुरोधित देरी निर्धारित प्रतीक्षा से लंबी है, तो वह उसकी जगह ले लेती है, लेकिन निर्धारित प्रतीक्षा के दोगुने तक ही। छोटी देरी का कोई असर नहीं होता, इसलिए यह हेडर फिर से प्रयास को पहले नहीं ला सकता। इसके बाद परिणाम पर यादृच्छिक समायोजन लागू होता है। शेड्यूल को सटीक समय-सीमा के बजाय रिकवरी की अवधि मानें।

हर फिर से प्रयास में इवेंट का webhook-id बना रहता है, ताकि आपका रिसीवर डुप्लिकेट पहचान सके।

आखिरी फिर से प्रयास के बाद क्या होता है?

उस डिलीवरी के लिए स्वचालित रूप से फिर से प्रयास करना बंद हो जाता है। विफल हुई डिलीवरी के लिए आप रीप्ले का अनुरोध कर सकते हैं।

आप createWebhookReplay से या एंडपॉइंट के डैशबोर्ड पेज से दोबारा डिलीवरी का अनुरोध करते हैं। रीप्ले डिलीवरी-प्रयास लॉग पढ़ता है और उसमें विफल हुए इवेंट चुनता है। जिस इवेंट के लिए Bird ने कभी प्रयास नहीं किया, जैसे एंडपॉइंट रुके रहने के दौरान आया इवेंट, उसका चुनने लायक कोई प्रयास नहीं होता, इसलिए रीप्ले उसे वापस नहीं ला सकता।

प्रतिक्रिया 202 होती है, जिसका अर्थ है कि रीप्ले बैकग्राउंड में चलने के लिए कतार में है। इसमें कोई गिनती या टास्क पहचानकर्ता नहीं होता। बाद के प्रयास देखने के लिए listWebhookAttempts का उपयोग करें।

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

रीप्ले उन डिलीवरी को छोड़ देता है जिनकी सफल पावती पहले ही दी जा चुकी है। दोबारा डिलीवरी में मूल webhook-id बना रहता है, इसलिए डुप्लिकेट संभालने का आपका तरीका तब भी लागू होता है।

रिकवरी विंडो की सीमा तय करने के लिए since और until को date-time स्ट्रिंग के रूप में सेट करें। दोनों सीमाएँ शामिल होती हैं। दोनों की तुलना डिलीवरी प्रयास के समय से होती है, इवेंट होने के समय से नहीं। since छोड़ने पर विंडो अनुरोध से 24 घंटे पहले शुरू होती है, इसलिए पुराने आउटेज के लिए स्पष्ट शुरुआती समय देना होगा। until छोड़ने पर विंडो अनुरोध के समय खत्म होती है।

प्रयास तीन दिन तक रखे जाते हैं, और रीप्ले इतना ही पीछे तक पहुँचता है। इससे पहले का since विंडो को बड़ा करता है, पर इससे पुराना कुछ भी वापस नहीं लाता। एक रीप्ले विंडो के अधिकतम 10,000 सबसे पुराने इवेंट ही कवर करता है, इसलिए लंबे आउटेज के लिए कई छोटी विंडो चाहिए।

एक संगठन प्रति UTC दिन 20 रीप्ले का अनुरोध कर सकता है। इसके बाद के अनुरोध को WebhookReplayQuotaExceeded के साथ 429 मिलता है, इसलिए हर इवेंट के लिए अलग रीप्ले माँगने के बजाय रिकवरी को एक विंडो में जोड़ें।

अगर मेरा एंडपॉइंट लगातार विफल होता रहे तो क्या होगा?

Bird विफल हो रहे एंडपॉइंट को डिग्रेडेड चिह्नित करता है। लगभग पाँच दिन तक लगातार विफलता के बाद वह डिलीवरी रोक देता है।

आप इसका status active, degraded या paused के रूप में पढ़ सकते हैं। डिग्रेडेड एंडपॉइंट को डिलीवरी और फिर से प्रयास मिलते रहते हैं। एक सफल डिलीवरी डिग्रेडेशन हटा देती है और लगातार विफलता की घड़ी को रीसेट कर देती है।

पॉज़ किया गया एंडपॉइंट इवेंट प्राप्त करना बंद कर देता है और अपने आप फिर से शुरू नहीं होता। updateWebhook से status को active पर सेट करके इसे फिर से सक्षम करें। फिर उस समय-सीमा को रीप्ले करें, जिससे पॉज़ से पहले विफल हुई डिलीवरी वापस मिल जाती हैं। पहले फिर से सक्षम करें: एंडपॉइंट के पॉज़ रहते हुए अनुरोध किया गया रीप्ले 202 लौटाता है और कुछ भी दोबारा डिलीवर नहीं करता। लिखने योग्य स्टेटस मान active और paused हैं।

प्राप्त करने वाला url बदलने या एक सफल टेस्ट डिलीवरी पूरी होने से भी डिग्रेडेशन हट जाता है। नया URL सार्वजनिक रूप से पहुँच योग्य HTTPS होना चाहिए, इसलिए निजी पते पहुँच की समस्या ठीक नहीं कर सकते। 2,048 वर्णों से लंबे URL सत्यापन में विफल होते हैं, इसलिए जनरेट किए गए URL को सबमिट करने से पहले छोटा करें।

एंडपॉइंट का विवरण या इवेंट सब्सक्रिप्शन बदलने से यह साबित नहीं होता कि वह अनुरोध प्राप्त कर सकता है। इन बदलावों के बाद डिग्रेडेशन बना रहता है, और विफल टेस्ट डिलीवरी के बाद भी।

जब कोई एंडपॉइंट डिग्रेडेड होता है, तो Bird संगठन के मालिकों को ईमेल भेजता है। एंडपॉइंट के ठीक होने तक यह डिग्रेडेशन का कोई और ईमेल नहीं भेजता। इसलिए बार-बार की विफलताओं पर हर प्रयास के लिए ईमेल नहीं आता। ठीक होने के बाद हुई विफलता डिग्रेडेशन की एक नई अवधि शुरू करती है। Bird हर एंडपॉइंट के लिए 24 घंटे में अधिकतम एक डिग्रेडेशन ईमेल भेजता है, इसलिए उस समय के भीतर ठीक होकर फिर विफल होने वाले एंडपॉइंट के लिए दूसरा ईमेल नहीं आता। प्राप्त करने वाला url बदलने से यह सीमा रीसेट हो जाती है, इसलिए नए URL पर पहला डिग्रेडेशन पिछले ईमेल के 24 घंटे के भीतर भी ईमेल भेज सकता है।

क्या कोई डेड-लेटर क्यू है?

Bird विफल इवेंट की कोई अलग क्यू नहीं देता जिसे आप पढ़ सकें। इसके बजाय डिलीवरी प्रयास देखें और रीप्ले का अनुरोध करें।

रिसीवर को ठीक करें, ज़रूरत हो तो उसे फिर से सक्षम करें और प्रभावित समय-सीमा को रीप्ले करें। इसके बाद खाली करने के लिए कोई अलग कतार नहीं होती।

क्या इवेंट क्रम से पहुँचते हैं?

इवेंट उस क्रम से अलग क्रम में पहुँच सकते हैं जिसमें वे घटित हुए थे।

कोई email.delivered इवेंट उसी संदेश के email.accepted इवेंट से पहले पहुँच सकता है। ऐसा बदलाव लागू करने से पहले जो नई स्थिति को ओवरराइट कर दे, timestamp में इवेंट के समय की तुलना करें।

SMS शुल्क के हर हिस्से को अलग से ट्रैक करें। उदाहरण के लिए, डिलीवरी शुल्क और कैरियर शुल्क अलग-अलग लागत घटक हैं।

जब तक किसी घटक की कीमत तय नहीं होती, cost ऑब्जेक्ट null रहता है। इसके घटक मान दशमलव स्ट्रिंग या null होते हैं। amount फ़ील्ड एक दशमलव स्ट्रिंग है, जो उस पेलोड में मौजूद घटकों का योग होती है।

हर घटक को उसके सबसे नए इवेंट टाइमस्टैम्प के आधार पर मर्ज करें। पूरे ऑब्जेक्ट को बदल देने से किसी दूसरे इवेंट से आया घटक मिट सकता है, या कोई पुराना शुल्क वापस आ सकता है।

null घटक का अर्थ है कि उस पेलोड में उसकी कीमत तय नहीं हुई थी। इसका अर्थ शून्य शुल्क नहीं है। SMS इवेंट इस मर्ज को संदर्भ में समझाता है, और वेबहुक डिलीवरी के व्यवहार को बताता है।