कनेक्शन टूटने पर आपको यकीन नहीं रहता कि भेजने की रिक्वेस्ट सफल हुई या नहीं। खोई हुई acknowledgment के कारण webhook सेंडर वही event दोबारा डिलीवर कर सकता है जो आपके ऐप्लिकेशन ने पहले ही स्टोर कर लिया था।
ये विफलताएँ विपरीत दिशाओं में होती हैं। Bird आपके द्वारा दी गई key से दोहराई गई API रिक्वेस्ट को पहचान सकता है। आपके webhook रिसीवर को स्वीकृत events का अपना अलग रिकॉर्ड रखना होगा।
भेजने का फिर से प्रयास सुरक्षित रूप से कैसे करें?
एक लॉजिकल API ऑपरेशन के हर प्रयास के लिए वही Idempotency-Key हेडर दोबारा उपयोग करें।
आप key चुनते हैं, अधिकतम 255 कैरेक्टर, और रीट्राइज़ में उसे बनाए रखते हैं। welcome-user/usr_abc123 जैसा स्थिर मान आपकी प्रक्रिया रीस्टार्ट होने के बाद भी एक welcome-message ऑपरेशन की पहचान कर सकता है।
यह हेडर POST, PATCH और DELETE जैसी म्यूटेटिंग रिक्वेस्ट पर लागू होता है। बिना key वाली रिक्वेस्ट इस deduplication के बिना प्रोसेस होती है। GET हेडर को अनदेखा करता है क्योंकि रिसोर्स पढ़ना पहले से ही दोहराने में सुरक्षित है।
Bird मैच होने वाली पूर्ण रिक्वेस्ट के लिए स्टोर की गई प्रतिक्रिया लौटाता है, जिसमें उसका मूल स्टेटस और बॉडी शामिल होती है। प्रतिक्रिया में Idempotency-Replay: true होता है, जिससे आप अपने लॉग में इस पुनः उपयोग की पहचान कर सकते हैं।
Idempotency गाइड पूर्ण-प्रतिक्रिया विंडो के लिए तीन घंटे का डिफ़ॉल्ट दर्शाती है। इसके समाप्त होने के बाद रीट्राई एक नए ऑपरेशन के रूप में चल सकता है। डुप्लिकेट भेजने से रोकने के लिए उस key पर स्थायी रूप से निर्भर न रहें।
Bird SDK म्यूटेशन के लिए key जनरेट करते हैं और अपनी आंतरिक रीट्राइज़ में उसे दोबारा उपयोग करते हैं। Bird CLI भी म्यूटेटिंग रिक्वेस्ट के लिए key जनरेट करता है जब कोई key अनुपस्थित हो। जब अलग-अलग कमांड इनवोकेशन को एक ही ऑपरेशन साझा करना हो तो --idempotency-key स्पष्ट रूप से सेट करें।
SMTP सबमिशन के लिए X-Bird-Idempotency-Key मैसेज हेडर उपयोग करें। इससे दोबारा सबमिट की गई रिक्वेस्ट उसी ऑपरेशन की पहचान कर सकती है।
गलत तरीके से key दोबारा उपयोग करने पर क्या होता है?
Bird किसी अलग ऑपरेशन की प्रतिक्रिया लौटाने के बजाय विरोधी key उपयोग को अस्वीकार करता है।
| स्थिति | प्रतिक्रिया और सुधार |
|---|---|
| पूर्णता के बाद वही key और रिक्वेस्ट | Idempotency-Replay: true के साथ स्टोर की गई प्रतिक्रिया। |
| पूर्ण key अलग रिक्वेस्ट के लिए दोबारा उपयोग | 409 E01005 के साथ, अर्थात् idempotency key पुनः उपयोग। रीट्राई से पहले key ठीक करें। |
| उस key वाली एक और रिक्वेस्ट अभी चल रही है | 409 E01004 के साथ, अर्थात् रिक्वेस्ट प्रगति में है। थोड़ा प्रतीक्षा करें और फिर से प्रयास करें। |
| Key 255 कैरेक्टर से अधिक है | 400 E01002 के साथ, अर्थात् अमान्य इनपुट। Key छोटी करें। |
तुलना में method, endpoint, path parameters, query string और body शामिल हैं। JSON के लिए, whitespace बदलने से रिक्वेस्ट की पहचान बदल जाती है, इसलिए रीट्राइज़ के दौरान मूल बॉडी को बनाए रखें।
अधूरे ऑपरेशन पर लगा lock तीस सेकंड के भीतर समाप्त हो जाता है। यह सीमा छोड़े गए ऑपरेशन के बाद दूसरी रिक्वेस्ट को आगे बढ़ने देती है। यह स्थापित नहीं करता कि कोई साइड इफ़ेक्ट पहले ही हो चुका है या नहीं।
Bird रीप्ले के लिए 5xx प्रतिक्रिया स्टोर नहीं करता। सर्वर त्रुटि या timeout पर उसी key से फिर से प्रयास करें ताकि रिकॉर्ड की गई सफलता अभी भी दोबारा उपयोग की जा सके।
वैलिडेशन या बिज़नेस-रूल अस्वीकृति key को रिलीज़ कर देती है। आप उस अस्वीकृत रिक्वेस्ट को सही करके उसी key के तहत फिर से प्रयास कर सकते हैं क्योंकि कोई पूर्ण प्रतिक्रिया रिटेन नहीं की गई थी।
मुझे एक ही webhook दो बार क्यों मिलता है?
Bird आपके रिसीवर द्वारा पहले से स्टोर किए गए event को फिर से भेज सकता है यदि उसे सफल प्रतिक्रिया नहीं मिलती।
रिसीवर किसी event को स्टोर कर सकता है ठीक उसके कनेक्शन टूटने से पहले। Bird को कोई सफल acknowledgment नहीं दिखती और वह फिर से प्रयास करता है, भले ही रिसीवर के पास event पहले से मौजूद हो।
हर रीट्राई में वही webhook-id हेडर बना रहता है, जो event की पहचान करता है। छूटी हुई डिलीवरी का रीप्ले भी वह identifier बनाए रखता है, इसलिए दोनों को एक ही event के रूप में पहचाना जा सकता है।
अपने हैंडलर को idempotent कैसे बनाएँ?
Event का काम शेड्यूल करने से पहले हर webhook-id को एक unique database constraint के तहत स्टोर करें।
इन्सर्ट करने से पहले मौजूदा row की जाँच करने में race condition रहती है: दो समवर्ती रिक्वेस्ट दोनों को कोई row नहीं दिख सकती। डेटाबेस को डुप्लिकेट identifiers अस्वीकार करने दें।
Identifier और job को एक ही transaction में स्टोर करें। इससे बिना कोई काम कतार में डाले identifier रिकॉर्ड होने से रोका जा सकता है।
- रिक्वेस्ट सत्यापित करें, फिर उसका identifier और job एक ही transaction में इन्सर्ट करें।
- उस transaction के commit होने के बाद
2xxलौटाएँ, ताकि Bird रीट्राई करना बंद कर सके। - स्टोर किए गए job को एक ऐसे worker में प्रोसेस करें जो अपनी क्रियाएँ सुरक्षित रूप से दोहरा सके।
पहले से commit हुए डुप्लिकेट identifier के लिए, दूसरी job बनाए बिना सफलता लौटाएँ। विफल transaction के लिए, त्रुटि लौटाएँ ताकि Bird फिर से प्रयास करे।
धीमे काम को रिसीवर से बाहर रखें क्योंकि उसकी प्रतीक्षा करने से रिक्वेस्ट टाइम आउट हो सकती है। Worker webhook डिलीवरी से असंबंधित कारणों से रीट्राई कर सकता है, इसलिए केवल रिसीवर की सुरक्षा अपर्याप्त है।
Events क्रम से बाहर भी आ सकते हैं। नए state को ओवरराइट करने से पहले timestamp में event times की तुलना करें। विफल webhook रीट्राइज़ में आंशिक-लागत उदाहरण शामिल है।
किस पर निर्भर नहीं रहना चाहिए?
यह न मानें कि रिक्वेस्ट deduplication डुप्लिकेट साइड इफ़ेक्ट को असंभव बना देता है।
यदि Bird का deduplication स्टोर अनुपलब्ध है, तो रिक्वेस्ट उसके बिना आगे बढ़ती हैं। जहाँ किसी क्रिया का दोहराया जाना हानिकारक हो, वहाँ बिज़नेस-लेवल सुरक्षा बनाए रखें।
इसी तरह, webhook-id एक event की दोहराई गई डिलीवरी को अलग पहचानता है। अलग-अलग events के अलग identifiers होते हैं। आपका ऐप्लिकेशन अभी भी यह तय करता है कि वे events उसी क्रिया को दोहराने का औचित्य रखते हैं या नहीं।
Idempotency API रीट्राई व्यवहार दर्शाता है। Webhooks उन अलग डिलीवरी गारंटियों को कवर करता है जिन्हें आपका रिसीवर हैंडल करता है।
संक्षेप में
API रीट्राइज़ और webhook रीट्राइज़ को अलग-अलग रिकॉर्ड चाहिए।
Bird को रिक्वेस्ट भेजते समय Idempotency-Key दोबारा उपयोग करें। आपका रिसीवर webhook-id स्टोर करता है ताकि पहले से स्वीकृत event को पहचान सके।
अस्वीकृत रिक्वेस्ट अपनी key रिलीज़ कर सकती हैं।
वैलिडेशन और बिज़नेस-रूल त्रुटियाँ कोई पूर्ण प्रतिक्रिया नहीं छोड़तीं, जिससे उसी key के तहत सही किया हुआ फिर से प्रयास किया जा सकता है।
एक पूर्ण key अलग रिक्वेस्ट की पहचान नहीं कर सकती।
बदली हुई JSON बॉडी या endpoint 409 conflict उत्पन्न कर सकता है। उस conflict को वैसे ही रीट्राई करने के बजाय key ठीक करें।
Deduplication की सीमाएँ हैं।
Deduplication स्टोर अनुपलब्ध होने पर रिक्वेस्ट बिना उसके आगे बढ़ती हैं। अपने ऐप्लिकेशन में भी दोहराई गई क्रियाओं को सुरक्षित रखें।