एरर कैटलॉग क्या है, और एरर कोड को रीट्राई से कैसे मैप करें?

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

मुझे कौन-से एरर फ़ील्ड उपयोग करने चाहिए?

व्यापक हैंडलिंग के लिए type और विशिष्ट रिकवरी के लिए code का उपयोग करें। Bird इन फ़ील्ड को एक टॉप-लेवल error ऑब्जेक्ट के अंदर रखता है।

type विफलताओं को समूहित करता है जैसे सत्यापन, प्रमाणीकरण और अनुरोध दर सीमित करना। code विशिष्ट विफलता की पहचान करता है, जैसे फ़ील्ड सत्यापन के लिए E01001।

Bird कभी किसी कोड का नाम नहीं बदलता और न ही उसे दोबारा उपयोग करता है। रिटायर किए गए कोड आरक्षित रहते हैं, इसलिए मौजूदा कोड मैच अपना अर्थ बनाए रखता है।

message को दिखाएँ या लॉग करें, लेकिन उसके टेक्स्ट को मैच न करें। शब्द बदल सकते हैं बिना उस विफलता को बदले जिसे आपके हैंडलर को संभालना है।

name लॉग को पठनीय बनाता है। doc_url कोड के दस्तावेज़ से लिंक करता है। जब कोई ऑपरेशन विफल हो तो code, name और request_id को एक साथ लॉग करें।

किन विफलताओं को फिर से प्रयास करना चाहिए?

अस्थायी विफलताओं को एक सीमित नीति के साथ फिर से प्रयास करें। दोबारा प्रयास करने से पहले इनपुट और क्रेडेंशियल समस्याओं को ठीक करें। जब एक ही स्टेटस को अलग-अलग कार्रवाई की ज़रूरत हो तो विशिष्ट कोड जाँचें।

एक ही write को फिर से प्रयास करते समय वही idempotency key रखें। टाइमआउट या सर्वर विफलता यह साबित नहीं करती कि मूल ऑपरेशन ने कुछ नहीं किया।

जब फिर से प्रयास का बजट समाप्त हो जाए तो रुकें और अंतिम एरर रिकॉर्ड करें। अपरिवर्तित अनुरोध को अनिश्चितकाल दोहराना ऐसी विफलता छिपा सकता है जिसमें हस्तक्षेप ज़रूरी है।

फ़ील्ड सत्यापन एरर कैसे हैंडल करें?

E01001 ValidationError पर details ऐरे पढ़ें और प्रत्येक एंट्री को उसके param से जोड़ें। उस एंट्री का message प्रभावित फ़ील्ड के बगल में दिखाएँ।

फ़ील्ड या विफलता पहचानने के लिए उन मैसेज को पार्स न करें। उनके शब्द बदल सकते हैं, ठीक टॉप-लेवल मैसेज की तरह।

एक विकृत अनुरोध इसके बजाय E01002 InvalidRequest लौटा सकता है। यह मानने के बजाय कि हर इनपुट विफलता में फ़ील्ड-लेवल विवरण होते हैं, उसकी दस्तावेज़ित रिकवरी का उपयोग करें।

क्या प्रतिक्रिया मुझे रिकवरी का तरीका बता सकती है?

कुछ एरर में remediation, एक human-readable अगला कदम, या next, प्रयास करने के लिए ऑपरेशनों की क्रमबद्ध सूची शामिल होती है।

जब remediation व्यक्ति को समस्या ठीक करने में मदद करे तो उसे दिखाएँ। उदाहरण के लिए, एक authorization विफलता के लिए अतिरिक्त scope वाले क्रेडेंशियल की ज़रूरत हो सकती है।

एक स्वचालित हैंडलर रिकवरी ऑपरेशन चुनने के लिए next का उपयोग कर सकता है। फिर भी उसे निष्पादित करने से पहले उस ऑपरेशन के इनपुट और अनुमतियों की ज़रूरत होती है।

एक vendor_code डाउनस्ट्रीम विफलता की पहचान करता है, जैसे SMTP प्रतिक्रिया या पेमेंट डिक्लाइन। जब रिकवरी उस प्रोवाइडर पर निर्भर हो तो उसके कोड देखें।

अपरिचित कोड के लिए क्या करना चाहिए?

एक डिफ़ॉल्ट ब्रांच रखें जो बिना क्रैश या अनिश्चितकाल फिर से प्रयास किए विफलता रिकॉर्ड करे। जैसे-जैसे API बढ़ता है, नए कोड और टाइप आ सकते हैं।

जहाँ उचित हो, ज्ञात स्टेटस-आधारित रीट्राई नीति लागू करें। अन्यथा, रुकें और जाँच के लिए कोड को उसकी request ID के साथ लॉग करें।

एरर गाइड त्रुटि प्रतिक्रिया का दस्तावेज़ देता है। एरर रेफ़रेंस व्यक्तिगत कोड और उनकी रिकवरी मार्गदर्शन सूचीबद्ध करता है।