त्रुटि कैटलॉग क्या है, और मैं त्रुटि कोड को फिर से प्रयास से कैसे जोड़ूँ?

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

मुझे कौन-से त्रुटि फ़ील्ड इस्तेमाल करने चाहिए?

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

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

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

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

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

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

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

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

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

फ़ील्ड सत्यापन त्रुटियों को कैसे संभालें?

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

फ़ील्ड या विफलता पहचानने के लिए उन संदेशों को पार्स न करें। शीर्ष-स्तरीय संदेश की तरह उनके शब्द भी बदल सकते हैं।

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

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

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

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

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

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

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

एक डिफ़ॉल्ट ब्रांच रखें जो क्रैश हुए बिना या लगातार फिर से प्रयास किए बिना विफलता को दर्ज करे। API के बढ़ने के साथ नए कोड और प्रकार सामने आ सकते हैं।

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

त्रुटि गाइड त्रुटि प्रतिक्रिया का प्रारूप बताती है। त्रुटि संदर्भ में अलग-अलग कोड और उनसे उबरने के निर्देश दिए गए हैं।