यदि इंटरफ़ेस किसी त्रुटि की रिपोर्ट करता है, तो पुनः प्रयास करें? दस्तावेज़ीकरण कार्यों को पहले यह भेद करना चाहिए कि किन विफलताओं को पुनर्प्राप्त किया जा सकता है

किसी त्रुटि की सूचना मिलने के बाद पुनः प्रयास करना एक सामान्य अभ्यास है, लेकिन यदि आप अनिश्चित काल तक अंधाधुंध पुनः प्रयास करते हैं, तो गड़बड़ियाँ बढ़ सकती हैं। अनुमति त्रुटियाँ, खाता विलंब, क्षतिग्रस्त फ़ाइलें और अस्थायी व्यस्त सेवाओं को अलग तरीके से संभाला जाना चाहिए।

यह आलेख उन डेवलपर्स और उत्पाद छात्रों के लिए उपयुक्त है जो दस्तावेज़ अनुवाद और रूपांतरण जैसे अतुल्यकालिक कार्य कर रहे हैं। इसे पढ़ने के बाद, आप पहले विफलताओं को वर्गीकृत कर सकते हैं और फिर तय कर सकते हैं कि कितनी देर तक इंतजार करना है, अधिकतम कितने प्रयास करना है और कब उपयोगकर्ता के हस्तक्षेप की आवश्यकता है।

नीचे दिए गए कोड और प्रवाह सिंथेटिक नमूनों पर आधारित हैं जिनका एक अलग वातावरण में परीक्षण किया गया है। वे सभी प्रामाणिक दस्तावेज़ों या उत्पाद प्रभावों की गारंटी का प्रतिनिधित्व नहीं करते हैं। कृपया महत्वपूर्ण दस्तावेज़ों को संसाधित करने से पहले मूल प्रतियाँ अपने पास रखें और पाठ में सीमाओं और स्वीकृति मदों के अनुसार उनकी समीक्षा करें।

दस्तावेज़ कार्य में त्रुटि रिपोर्ट होने के बाद पुनः प्रयास कैसे करें? एक वाक्य का निष्कर्ष

दोबारा प्रयास करना है या नहीं, यह तय करने से पहले विफलता को वर्गीकृत करें: अस्थायी विफलताओं को सीमित कर दिया जाता है और वापस ले लिया जाता है, अनुमति और खाता संबंधी समस्याएं रोक दी जाती हैं और उपयोगकर्ता को सौंप दी जाती हैं, और इनपुट त्रुटियों को ठीक करने के लिए उपयोगकर्ता पर छोड़ दिया जाता है।

पहले यह निर्धारित करें कि क्या पुनः प्रयास करने से डुप्लिकेट कार्य उत्पन्न होंगे।

POST टाइमआउट विशेष रूप से परेशानी भरा है। यदि क्लाइंट को कोई प्रतिक्रिया नहीं मिलती है, तो इसका मतलब यह नहीं है कि सर्वर ने कोई कार्य नहीं बनाया है। यदि इंटरफ़ेस में इडेम्पोटेंट कुंजियाँ नहीं हैं और कार्य क्वेरी तंत्र नहीं है, तो ब्लाइंड रीसेंडिंग कई अनुवाद कार्य बना सकता है।

इसलिए, पुनः प्रयास रणनीति को केवल HTTP स्थिति कोड को देखने के बजाय इंटरफ़ेस अनुबंध का अधिमानतः पालन करना चाहिए।

समय की संख्या और प्रतीक्षा बजट को शुद्ध कार्यों के रूप में लिखें

from enum import Enum

class Failure(Enum):
    TRANSIENT = "transient"
    AUTH = "auth"
    BILLING = "billing"
    INVALID_INPUT = "invalid_input"

def delay_for(kind, attempt, replay_safe):
    if type(attempt) is not int or attempt < 0:
        raise ValueError("invalid attempt")
    if not replay_safe or kind is not Failure.TRANSIENT:
        return None
    schedule = (1, 2, 4)
    return schedule[attempt] if attempt < len(schedule) else None

assert delay_for(Failure.TRANSIENT, 0, True) == 1
assert delay_for(Failure.TRANSIENT, 2, True) == 4
assert delay_for(Failure.TRANSIENT, 3, True) is None
assert delay_for(Failure.TRANSIENT, 0, False) is None
assert delay_for(Failure.BILLING, 0, True) is None
assert delay_for(Failure.INVALID_INPUT, 0, True) is None

यह कोड केवल पुनः प्रयास योजना की गणना करता है, वास्तव में प्रतीक्षा नहीं करता है, और अनुरोध नहीं भेजता है। निश्चित एक, दो और चार सेकंड सिंथेटिक प्रदर्शन के मूल्य हैं और सामान्य सेवा अनुशंसाएँ नहीं हैं।

उत्पादन परिवेश को निम्नलिखित बातों पर भी विचार करने की आवश्यकता है:

• Retry-After सर्वर द्वारा लौटाया गया
• एक ही समय में बड़ी संख्या में कार्यों को फिर से शुरू करने से बचने के लिए यादृच्छिक घबराहट
• कुल मिलाकर समय सीमा
• समवर्ती की संख्या पर सीमा

यदि सर्वर द्वारा आवश्यक प्रतीक्षा समय स्थानीय बजट से अधिक हो जाता है, तो उसे पहले से अनुरोध शुरू करने के बजाय पुनः प्रयास करना बंद कर देना चाहिए।

त्रुटि प्रकार विभिन्न क्रियाओं से मेल खाते हैं

तार्किक कार्यों को सहेजें और रिकॉर्ड का प्रयास करें

एक उपयोगकर्ता ऑपरेशन एक तार्किक कार्य से मेल खाता है, और इस तार्किक कार्य के तहत कई प्रयास हो सकते हैं। प्रत्येक प्रयास के लिए प्रारंभ समय, विफलता श्रेणी और दूरस्थ कार्य आईडी लॉग की जाती है। अंत में, केवल एक स्वीकृत परिणाम का चयन किया जाता है।

इसका लाभ यह है कि पुन: प्रयास की समस्याओं का निवारण करते समय एक पूरा रिकॉर्ड होता है, और साथ ही, प्रयासों की संख्या को उपयोगकर्ता के अनुरोधों की संख्या में गलत तरीके से शामिल नहीं किया जाएगा।

📊 कोर तुलना

अनुवाद अनुभव की स्थिरता स्पष्ट स्पष्टीकरण से आती है

OmniDoc से कनेक्ट करते समय, फ्रंट एंड को उपयोगकर्ता को वर्तमान स्थिति स्पष्ट रूप से बतानी चाहिए: क्या वह प्रतीक्षा कर रहा है, पुनः अधिकृत करने की आवश्यकता है, या खाते की जांच करने की आवश्यकता है। हर चीज़ को "बिल्डिंग" के रूप में प्रदर्शित न करें।

उपयोगकर्ता स्थिति और निकास के साथ किसी कार्य की प्रतीक्षा करने को तैयार हैं, लेकिन बिना किसी प्रतिक्रिया के बार-बार एक बटन पर क्लिक करने को तैयार नहीं हैं।

संदर्भ: Python enum.

🎯कौन सा तरीका आपके लिए उपयुक्त है?

यदि आप सेवा बहाल होने का इंतजार कर रहे हैं

बाउंडेड बैकऑफ़ का उपयोग करें, अधिकतम समय और कुल प्रतीक्षा समय निर्धारित करें, और सर्वर केRetry-After का सम्मान करें।

यदि आपके पास अनुमति या खाता संबंधी समस्याएं हैं

स्वचालित पुनर्प्रयास रोकें और उपयोगकर्ता को पुन: प्राधिकृत करने या खाता स्थिति जांचने के लिए कहें।

यदि आपकी इनपुट फ़ाइल संरचना गलत है

सबमिट करने से पहले उपयोगकर्ता को फ़ाइल सुधारने दें। उसी फ़ाइल को दोबारा न भेजें.

यदि आप जिस इंटरफ़ेस पर कॉल करते हैं वह POST है और समय समाप्त हो सकता है

पहले पुष्टि करें कि क्या इंटरफ़ेस इडेम्पोटेंट कुंजियों या कार्य क्वेरी का समर्थन करता है, और फिर तय करें कि दोबारा भेजना है या नहीं।

❓ अक्सर पूछे जाने वाले प्रश्न (FAQ)

1. क्या रिपोर्ट की गई सभी त्रुटियों का सीधे पुनः प्रयास किया जा सकता है?

नहीं कर सकता। अनुमति त्रुटियाँ, खाता बकाया, क्षतिग्रस्त फ़ाइलें और अस्थायी व्यस्त सेवाओं को अलग से संभाला जाना चाहिए। बाउंडेड बैकऑफ़ के लिए केवल अस्थायी विफलताएँ उपयुक्त हैं।

2. क्या समय समाप्त होने के बाद POST सीधे दोबारा भेजा जा सकता है?

इसे सीधे पुनः भेजने की अनुशंसा नहीं की जाती है. यदि क्लाइंट को कोई प्रतिक्रिया नहीं मिलती है, तो इसका मतलब यह नहीं है कि सर्वर ने कोई कार्य नहीं बनाया है। यदि कोई निष्क्रिय कुंजी या कार्य क्वेरी तंत्र नहीं है, तो डुप्लिकेट कार्य हो सकते हैं।

3. पुनः प्रयास की संख्या और प्रतीक्षा समय कैसे निर्धारित किया जाना चाहिए?

निर्धारित एक, दो और चार सेकंड केवल कृत्रिम प्रदर्शन हैं। उत्पादन वातावरण को Retry-After, यादृच्छिक घबराहट, समग्र समय सीमा और समवर्ती सीमाओं के संयोजन से निर्धारित किया जाना चाहिए।

4. क्या प्रयासों की संख्या उपयोगकर्ता अनुरोधों के आँकड़ों को प्रभावित करेगी?

नहीं, बस एक उपयोगकर्ता ऑपरेशन को एक तार्किक कार्य के रूप में रिकॉर्ड करें, और प्रत्येक पुनः प्रयास को कार्य के तहत एक प्रयास रिकॉर्ड के रूप में रिकॉर्ड करें।

📝सारांश

पुनः प्रयास करने की कुंजी अधिक बार प्रयास करना नहीं है, बल्कि पहले विफलता के प्रकार को पहचानना है और फिर तय करना है कि क्या करना है। जिन दोषों को पुनर्प्राप्त किया जा सकता है, उन्हें एक निश्चित तरीके से पुन: प्रयास किया जाता है, और जिन समस्याओं के लिए मानव प्रबंधन की आवश्यकता होती है, उन्हें उपयोगकर्ताओं को समय पर वापस कर दिया जाता है।

इसे अभी आज़माएं: मूल लेआउट को बरकरार रखते हुए अनुवाद शुरू करने के लिए दस्तावेज़ अपलोड करें