जर इंटरफेसमध्ये त्रुटी आढळल्यास, पुन्हा प्रयत्न करा? दस्तऐवजीकरण कार्यांनी प्रथम कोणते अपयश पुनर्प्राप्त केले जाऊ शकतात हे वेगळे केले पाहिजे

त्रुटी नोंदवल्यानंतर पुन्हा प्रयत्न करणे ही एक सामान्य गोष्ट आहे, परंतु आपण अनिश्चितपणे अनिश्चितपणे पुन्हा प्रयत्न केल्यास, त्रुटी वाढवल्या जाऊ शकतात. परवानगी त्रुटी, खात्यातील दोष, खराब झालेल्या फाइल्स आणि तात्पुरत्या व्यस्त सेवा वेगळ्या पद्धतीने हाताळल्या पाहिजेत.

हा लेख विकासक आणि उत्पादन विद्यार्थ्यांसाठी योग्य आहे जे दस्तऐवज भाषांतर आणि रूपांतरण यांसारखी अतुल्यकालिक कार्ये करत आहेत. हे वाचल्यानंतर, तुम्ही प्रथम अपयशांचे वर्गीकरण करू शकता आणि नंतर किती वेळ प्रतीक्षा करावी, जास्तीत जास्त किती प्रयत्न करावेत आणि वापरकर्त्याचा हस्तक्षेप कधी आवश्यक आहे हे ठरवू शकता.

खालील कोड आणि प्रवाह सिंथेटिक नमुन्यांवर आधारित आहेत ज्यांची चाचणी वेगळ्या वातावरणात केली गेली आहे. ते सर्व अस्सल दस्तऐवज किंवा उत्पादन प्रभावांची हमी दर्शवत नाहीत. कृपया महत्त्वाच्या कागदपत्रांवर प्रक्रिया करण्यापूर्वी मूळ ठेवा आणि मजकूरातील सीमा आणि स्वीकृती आयटमनुसार त्यांचे पुनरावलोकन करा.

दस्तऐवज कार्यात त्रुटी आढळल्यानंतर पुन्हा प्रयत्न कसा करावा? एका वाक्याचा निष्कर्ष

पुन्हा प्रयत्न करायचा की नाही हे ठरविण्यापूर्वी प्रथम अपयशाचे वर्गीकरण करा: तात्पुरते अपयश मर्यादित केले जातात आणि मागे घेतले जातात, परवानगी आणि खाते समस्या थांबवल्या जातात आणि वापरकर्त्याकडे सोपवल्या जातात आणि इनपुट त्रुटींचे निराकरण करण्यासाठी वापरकर्त्यावर सोडले जाते.

पुन्हा प्रयत्न केल्याने डुप्लिकेट कार्ये निर्माण होतील की नाही हे प्रथम निर्धारित करा.

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. नोंदवलेल्या सर्व त्रुटी थेट पुन्हा तपासल्या जाऊ शकतात?

करू शकत नाही. परवानगी त्रुटी, खाते थकबाकी, खराब झालेल्या फाइल्स आणि तात्पुरत्या व्यस्त सेवा स्वतंत्रपणे हाताळल्या पाहिजेत. केवळ तात्पुरते अपयश बाउंडेड बॅकऑफसाठी योग्य आहेत.

२. POST कालबाह्य झाल्यानंतर थेट पुन्हा पाठवता येईल का?

थेट पुन्हा पाठवण्याची शिफारस केलेली नाही. जर क्लायंटला प्रतिसाद मिळाला नाही, तर याचा अर्थ असा नाही की सर्व्हरने कार्य तयार केले नाही. कोणतीही अदम्य की किंवा कार्य क्वेरी यंत्रणा नसल्यास, डुप्लिकेट कार्ये उद्भवू शकतात.

3. पुन्हा प्रयत्नांची संख्या आणि प्रतीक्षा वेळ कसा ठरवावा?

निश्चित एक, दोन आणि चार सेकंद फक्त कृत्रिम प्रात्यक्षिके आहेत. उत्पादन वातावरण Retry-After, यादृच्छिक जिटर, एकूण मुदती आणि समवर्ती मर्यादा यांच्या संयोजनाने निर्धारित केले जावे.

४. प्रयत्नांची संख्या वापरकर्त्याच्या विनंत्यांच्या आकडेवारीवर परिणाम करेल का?

नाही, फक्त एक वापरकर्ता ऑपरेशन तार्किक कार्य म्हणून रेकॉर्ड करा आणि प्रत्येक पुन: प्रयत्न कार्य अंतर्गत प्रयत्न रेकॉर्ड म्हणून रेकॉर्ड करा.

📝 सारांश

पुन्हा प्रयत्न करण्याची गुरुकिल्ली म्हणजे अधिक वेळा प्रयत्न करणे नव्हे, तर प्रथम अपयशाचा प्रकार ओळखणे आणि नंतर काय करायचे ते ठरविणे. ज्या चुका पुनर्प्राप्त केल्या जाऊ शकतात त्या मर्यादित पद्धतीने पुन्हा प्रयत्न केल्या जातात आणि मानवी हाताळणी आवश्यक असलेल्या समस्या वापरकर्त्यांना वेळेवर परत केल्या जातात.

हे आता वापरून पहा: मूळ लेआउट कायम ठेवून भाषांतर सुरू करण्यासाठी दस्तऐवज अपलोड करा