இடைமுகம் பிழையைப் புகாரளித்தால், மீண்டும் முயற்சிக்கவா? எந்த தோல்விகளை மீட்டெடுக்க முடியும் என்பதை ஆவணப்படுத்தல் பணிகள் முதலில் வேறுபடுத்த வேண்டும்

ஒரு பிழை புகாரளிக்கப்பட்ட பிறகு மீண்டும் முயற்சிப்பது ஒரு பொதுவான நடைமுறையாகும், ஆனால் நீங்கள் காலவரையின்றி கண்மூடித்தனமாக மீண்டும் முயற்சித்தால், குறைபாடுகள் பெரிதாக்கப்படலாம். அனுமதி பிழைகள், கணக்கு தவறுகள், சேதமடைந்த கோப்புகள் மற்றும் தற்காலிக பிஸியான சேவைகள் ஆகியவை வித்தியாசமாக கையாளப்பட வேண்டும்.

ஆவண மொழிபெயர்ப்பு மற்றும் மாற்றம் போன்ற ஒத்திசைவற்ற பணிகளைச் செய்யும் டெவலப்பர்கள் மற்றும் தயாரிப்பு மாணவர்களுக்கு இந்தக் கட்டுரை பொருத்தமானது. இதைப் படித்த பிறகு, நீங்கள் முதலில் தோல்விகளை வகைப்படுத்தலாம், பின்னர் எவ்வளவு நேரம் காத்திருக்க வேண்டும், எத்தனை முயற்சிகள் மற்றும் பயனர் தலையீடு எப்போது தேவை என்பதை முடிவு செய்யலாம்.

கீழே உள்ள குறியீடு மற்றும் ஓட்டம் தனிமைப்படுத்தப்பட்ட சூழலில் சோதிக்கப்பட்ட செயற்கை மாதிரிகளை அடிப்படையாகக் கொண்டது. அவை அனைத்து உண்மையான ஆவணங்கள் அல்லது தயாரிப்பு விளைவுகளுக்கு உத்தரவாதம் அளிக்காது. முக்கியமான ஆவணங்களைச் செயலாக்குவதற்கு முன் அசல்களை வைத்து, உரையில் உள்ள எல்லைகள் மற்றும் ஏற்றுக்கொள்ளும் உருப்படிகளின்படி அவற்றை மதிப்பாய்வு செய்யவும்.

ஆவணப் பணி பிழையைப் புகாரளித்த பிறகு மீண்டும் முயற்சி செய்வது எப்படி? ஒரு வாக்கியத்தின் முடிவு

மீண்டும் முயற்சிக்கலாமா என்பதைத் தீர்மானிக்கும் முன் தோல்வியை முதலில் வகைப்படுத்தவும்: தற்காலிக தோல்விகள் கட்டுப்படுத்தப்பட்டு பின்வாங்கப்படும், அனுமதி மற்றும் கணக்குச் சிக்கல்கள் நிறுத்தப்பட்டு பயனரிடம் ஒப்படைக்கப்படும், மேலும் உள்ளீட்டுப் பிழைகள் பயனருக்குச் சரி செய்யப்படும்.

மீண்டும் முயற்சி செய்வது நகல் பணிகளை உருவாக்குமா என்பதை முதலில் தீர்மானிக்கவும்.

POST நேரமுடிவுகள் குறிப்பாக தொந்தரவாக உள்ளன. கிளையன்ட் பதிலைப் பெறவில்லை என்றால், சேவையகம் ஒரு பணியை உருவாக்கவில்லை என்று அர்த்தமல்ல. இடைமுகத்தில் idempotent விசைகள் இல்லை மற்றும் பணி வினவல் பொறிமுறை இல்லை என்றால், குருட்டு மறுபரிசீலனை பல மொழிபெயர்ப்பு பணிகளை உருவாக்கலாம்.

எனவே, மறுமுயற்சி உத்தியானது முதலில் 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. முயற்சிகளின் எண்ணிக்கை பயனர் கோரிக்கைகளின் புள்ளிவிவரங்களை பாதிக்குமா?

இல்லை, ஒரு பயனர் செயல்பாட்டை தர்க்கரீதியான பணியாகப் பதிவுசெய்து, ஒவ்வொரு மறுமுயற்சியையும் பணியின் கீழ் ஒரு முயற்சிப் பதிவாகப் பதிவுசெய்யவும்.

📝 சுருக்கம்

மீண்டும் முயற்சி செய்வதற்கான திறவுகோல், அதிக முறை முயற்சி செய்வதல்ல, ஆனால் தோல்வியின் வகையை முதலில் வேறுபடுத்தி பின்னர் என்ன செய்வது என்று முடிவு செய்வது. மீட்டெடுக்கக்கூடிய தவறுகள் வரம்பிற்குட்பட்ட முறையில் மீண்டும் முயற்சிக்கப்படுகின்றன, மேலும் மனித கையாளுதல் தேவைப்படும் சிக்கல்கள் சரியான நேரத்தில் பயனர்களுக்குத் திருப்பித் தரப்படும்.

இப்போது முயற்சிக்கவும்: அசல் தளவமைப்பைத் தக்கவைத்து, மொழிபெயர்ப்பைத் தொடங்க ஆவணத்தைப் பதிவேற்றவும்