आपका रिसीवर किसी इवेंट को तब भी स्टोर कर सकता है जब भेजने वाले को उसकी स्वीकृति कभी प्राप्त न हो। इसलिए फिर से प्रयास ऐसा काम दोहरा सकता है जो आपके ऐप्लिकेशन ने पहले ही स्वीकार कर लिया था।
फिर से प्रयास कुछ इवेंट में देरी करते हैं। नए इवेंट उन फिर से प्रयासों के पूरा होने से पहले आ सकते हैं। इवेंट आइडेंटिफ़ायर और घटना समय स्टोर करें ताकि ये डिलीवरी नए काम को ओवरराइट न कर सकें।
विफल डिलीवरी किसे माना जाता है?
Bird डिलीवरी को तब विफल मानता है जब उसे गैर-सफल प्रतिक्रिया मिलती है या अनुरोध टाइम आउट हो जाता है।
उस डिलीवरी के लिए फिर से प्रयास रोकने हेतु इवेंट स्टोर करने के बाद HTTP 2xx लौटाएँ। रीडायरेक्ट, क्लाइंट त्रुटि या सर्वर त्रुटि फिर से प्रयास के योग्य बनी रहती है।
उदाहरण के लिए, 400 अस्वीकृत अनुरोध को रिकॉर्ड करता है लेकिन Bird को उसे हटाने के लिए नहीं कहता। जब सिग्नेचर सत्यापन या टिकाऊ स्टोरेज विफल हो तो त्रुटि प्रतिक्रिया का उपयोग करें, ताकि डिलीवरी पुनर्प्राप्त की जा सके।
इवेंट को स्वीकार करने से पहले स्टोर करें। पहले सफलता लौटाने पर इवेंट खो सकता है अगर बाद का स्टोरेज ऑपरेशन विफल हो जाए।
धीमी प्रोसेसिंग को बैकग्राउंड वर्कर में रखें ताकि आपका रिसीवर शीघ्र प्रतिक्रिया दे सके। रिसीवर का काम उस प्रोसेसिंग के शुरू होने से पहले इवेंट को सत्यापित और संरक्षित करना है।
फिर से प्रयास का शेड्यूल क्या है?
Bird पहले प्रयास के बाद सात फिर से प्रयास विलंब का उपयोग करता है, कुल मिलाकर आठ प्रयास।
| फिर से प्रयास | पिछले प्रयास के बाद विलंब | समय समायोजन से पहले अनुमानित बीता हुआ समय |
|---|---|---|
| 1 | 5 सेकंड | 5 सेकंड |
| 2 | 5 मिनट | 5 मिनट 5 सेकंड |
| 3 | 30 मिनट | 35 मिनट 5 सेकंड |
| 4 | 2 घंटे | 2 घंटे 35 मिनट 5 सेकंड |
| 5 | 5 घंटे | 7 घंटे 35 मिनट 5 सेकंड |
| 6 | 10 घंटे | 17 घंटे 35 मिनट 5 सेकंड |
| 7 | 10 घंटे | 27 घंटे 35 मिनट 5 सेकंड |
यह शेड्यूल आपको स्वचालित प्रयास समाप्त होने से पहले रिसीवर की मरम्मत के लिए लगभग 27.5 घंटे देता है।
Bird आउटेज के बाद फिर से प्रयासों को फैलाने के लिए प्रत्येक प्रतीक्षा को किसी भी दिशा में 20 प्रतिशत तक यादृच्छिक रूप से समायोजित करता है। इसलिए पाँच मिनट का विलंब अन्य समायोजनों से पहले चार से छह मिनट तक हो सकता है।
थ्रॉटलिंग प्रतिक्रिया या टाइमआउट अगली प्रतीक्षा बदल सकता है। Bird Retry-After को भी ध्यान में रखता है, जो अगले प्रयास से पहले विलंब का अनुरोध करने वाला प्रतिक्रिया हेडर है। शेड्यूल को सटीक समय सीमा के बजाय पुनर्प्राप्ति विंडो मानें।
प्रत्येक फिर से प्रयास इवेंट की webhook-id बनाए रखता है, ताकि आपका रिसीवर डुप्लिकेट पहचान सके।
अंतिम फिर से प्रयास के बाद क्या होता है?
उस डिलीवरी के लिए स्वचालित फिर से प्रयास रुक जाते हैं। आप विफल हुई डिलीवरी का replay अनुरोध कर सकते हैं।
आप createWebhookReplay से या endpoint के डैशबोर्ड पेज से redelivery का अनुरोध करते हैं। Replay डिलीवरी-प्रयास लॉग पढ़ता है और वहाँ विफल हुए इवेंट चुनता है। कोई ऐसा इवेंट Bird जिसका कभी प्रयास नहीं किया गया, जैसे कि endpoint पॉज़ होने के दौरान आया इवेंट, उसके पास चुनने के लिए कोई प्रयास नहीं होता, इसलिए replay उसे पुनर्प्राप्त नहीं कर सकता।
प्रतिक्रिया 202 होती है, जिसका अर्थ है कि रीप्ले बैकग्राउंड में चलने के लिए कतारबद्ध है। इसमें कोई गिनती या टास्क आइडेंटिफ़ायर शामिल नहीं होता। बाद के प्रयासों की जाँच के लिए listWebhookAttempts का उपयोग करें।
प्रत्येक पुनर्वितरण ऊपर दिए गए शेड्यूल के बजाय एक प्रयास लेता है। Bird प्रयास रिकॉर्ड करता है और कार्य पूरा करता है, चाहे आपके रिसीवर ने इसे स्वीकार किया हो या नहीं। इसलिए अभी भी खराब रिसीवर में रीप्ले करने पर आठ के बजाय प्रति इवेंट एक अनुरोध खर्च होता है। रिसीवर ठीक करें, फिर दोबारा रीप्ले करें। ये विफलताएँ एंडपॉइंट स्वास्थ्य को प्रभावित नहीं करतीं। स्वीकृत पुनर्वितरण डिग्रेडेशन हटा देता है।
Replay पहले से सफलतापूर्वक स्वीकृत डिलीवरी को छोड़ देता है। Redelivery अपना मूल webhook-id रखती है, इसलिए आपकी डुप्लिकेट हैंडलिंग अभी भी लागू होती है।
रिकवरी विंडो को सीमित करने के लिए since और until को date-time स्ट्रिंग के रूप में सेट करें। दोनों सीमाएँ inclusive हैं। दोनों को डिलीवरी प्रयास के समय के आधार पर पढ़ा जाता है, न कि इवेंट घटित होने के समय के आधार पर। since छोड़ने पर विंडो अनुरोध से 24 घंटे पहले से शुरू होती है, इसलिए पुराने आउटेज के लिए स्पष्ट प्रारंभ समय देना ज़रूरी है। until छोड़ने पर विंडो अनुरोध के समय पर समाप्त होती है।
प्रयास तीन दिनों तक रखे जाते हैं, और रीप्ले उतना ही पीछे जा सकता है। पहले का since विंडो को चौड़ा करता है लेकिन उससे पुरानी चीज़ें रिकवर नहीं करता। एक रीप्ले विंडो में अधिकतम सबसे पुराने 10,000 इवेंट कवर करता है, इसलिए लंबी आउटेज के लिए कई छोटी विंडो की ज़रूरत होती है।
एक organization प्रति UTC दिन 20 replay अनुरोध कर सकता है। अतिरिक्त अनुरोध पर WebhookReplayQuotaExceeded के साथ 429 मिलता है, इसलिए प्रति इवेंट replay अनुरोध करने के बजाय रिकवरी को एक विंडो में जोड़ें।
अगर मेरा endpoint लगातार विफल होता रहे तो?
Bird विफल होते endpoint को degraded चिह्नित करता है। लगभग पाँच दिन की लगातार विफलताओं के बाद यह डिलीवरी पॉज़ कर देता है।
आप इसका status active, degraded या paused के रूप में पढ़ सकते हैं। एक degraded endpoint डिलीवरी और फिर से प्रयास प्राप्त करता रहता है। एक सफल डिलीवरी degradation हटा देती है और लगातार-विफलता की गिनती रीसेट कर देती है।
एक पॉज़ किया हुआ endpoint इवेंट प्राप्त करना बंद कर देता है और स्वचालित रूप से फिर से शुरू नहीं होता। इसे updateWebhook से फिर से सक्षम करें, status को active पर सेट करके। फिर विंडो replay करें, जो पॉज़ से पहले विफल हुई डिलीवरी पुनर्प्राप्त करता है। पहले फिर से सक्षम करें: endpoint अभी भी पॉज़ होने पर अनुरोधित replay 202 लौटाता है और कुछ भी redeliver नहीं करता। लिखने योग्य status मान active और paused हैं।
रिसीविंग url बदलने या सफल टेस्ट डिलीवरी पूरी करने से भी degradation हटता है। रिप्लेसमेंट URL सार्वजनिक रूप से पहुँच योग्य HTTPS होना चाहिए, इसलिए प्राइवेट पते reachability ठीक नहीं कर सकते। 2048 अक्षरों से लंबे URL वैलिडेशन में विफल होते हैं, इसलिए जनरेट किया हुआ URL सबमिट करने से पहले छोटा करें।
Endpoint का विवरण या इवेंट सब्सक्रिप्शन संपादित करना यह प्रमाणित नहीं करता कि वह अनुरोध प्राप्त कर सकता है। ये बदलाव degradation यथावत छोड़ते हैं, और विफल टेस्ट डिलीवरी भी।
Bird जब कोई endpoint degraded हो जाता है तो organization के मालिकों को ईमेल करता है। जब तक endpoint ठीक नहीं हो जाता, यह कोई और degradation ईमेल नहीं भेजता। इसलिए बार-बार की विफलताएँ हर प्रयास के लिए ईमेल नहीं बनातीं। ठीक होने के बाद की विफलता degradation की नई अवधि शुरू करती है।
क्या कोई dead-letter queue है?
Bird आपके पढ़ने के लिए विफल इवेंट की अलग queue प्रदान नहीं करता। इसके बजाय डिलीवरी प्रयासों का निरीक्षण करें और replay अनुरोध करें।
| रिकवरी कार्य | तंत्र |
|---|---|
| विफलताओं का निरीक्षण करें | डिलीवरी प्रयास हर HTTP अनुरोध का परिणाम और विलंब रिकॉर्ड करते हैं, नवीनतम पहले। |
| टूटे हुए रिसीवर को बार-बार डिलीवरी रोकें | पॉज़ करना endpoint को डिलीवरी से बाहर कर देता है। |
| विफल डिलीवरी पुनर्प्राप्त करें | Replay एक समय विंडो के भीतर redelivery का अनुरोध करता है। |
रिसीवर ठीक करें, ज़रूरत हो तो फिर से सक्षम करें और प्रभावित विंडो replay करें। बाद में खाली करने के लिए कोई अलग queue नहीं है।
क्या इवेंट क्रम में आते हैं?
इवेंट उस क्रम से भिन्न क्रम में आ सकते हैं जिसमें वे घटित हुए थे।
एक email.delivered इवेंट उसी संदेश के email.accepted इवेंट से पहले आ सकता है। कोई ऐसा बदलाव लागू करने से पहले जो नई स्थिति को अधिलेखित कर दे, timestamp में इवेंट समय की तुलना करें।
SMS शुल्क के हर भाग को अलग-अलग ट्रैक करें। उदाहरण के लिए, डिलीवरी शुल्क और कैरियर शुल्क अलग-अलग लागत घटक हैं।
cost ऑब्जेक्ट तब तक null होता है जब तक किसी घटक की कीमत नहीं लगाई जाती। इसके घटक मान दशमलव स्ट्रिंग या null होते हैं। amount फ़ील्ड एक दशमलव स्ट्रिंग है जो उस पेलोड में मौजूद घटकों का योग है।
हर घटक को उसके नवीनतम इवेंट टाइमस्टैम्प के आधार पर मर्ज करें। पूरे ऑब्जेक्ट को बदलने से किसी अन्य इवेंट द्वारा दिया गया घटक मिट सकता है, या पुराना शुल्क बहाल हो सकता है।
null घटक का अर्थ है कि उस पेलोड में इसकी कीमत नहीं लगाई गई। इसका अर्थ शून्य शुल्क नहीं है। SMS events उस मर्ज को संदर्भ में वर्णित करता है, और webhooks डिलीवरी सिमेंटिक्स को कवर करता है।
संक्षेप में
फिर से प्रयास एक निश्चित शेड्यूल पर होते हैं।
आठ प्रयास समय समायोजन से पहले लगभग 27.5 घंटे में फैले होते हैं। प्रतीक्षा में यादृच्छिक बदलाव फिर से प्रयासों को फैला देते हैं ताकि रिसीवर को एक साथ बड़ी संख्या में अनुरोध न मिलें।
टिकाऊ स्टोरेज के बाद ही स्वीकार करें।
2xx प्रतिक्रिया फिर से प्रयास रोक देती है और उस डिलीवरी को छूटे-इवेंट रीप्ले से बाहर कर देती है। त्रुटि प्रतिक्रिया उसे फिर से प्रयास के योग्य बनाए रखती है।
रुके हुए endpoint को मैन्युअल रूप से पुनर्प्राप्त करना होगा।
इसे फिर से सक्षम करें, फिर पॉज़ से पहले विफल हुई डिलीवरी को replay करें। जो इवेंट पॉज़ के दौरान आए उनका कभी प्रयास नहीं किया गया, इसलिए replay उन तक नहीं पहुँच सकता।
अपडेट लागू करने के लिए इवेंट समय का उपयोग करें।
डिलीवरी अक्रमित होती है। घटना के टाइमस्टैम्प की तुलना करें और आंशिक SMS लागतों को प्रति घटक मर्ज करें।