Pokud rozhraní hlásí chybu, zkusit to znovu? Úkoly dokumentace by měly nejprve rozlišit, která selhání lze obnovit

Opakování po nahlášení chyby je běžnou praxí, ale pokud to budete opakovat donekonečna bez rozdílu, mohou se závady zvětšit. Chyby oprávnění, delikvence účtů, poškozené soubory a dočasné zaneprázdněné služby by měly být řešeny jinak.

Tento článek je vhodný pro vývojáře a studenty produktů, kteří provádějí asynchronní úkoly, jako je překlad a konverze dokumentů. Po přečtení tohoto článku můžete nejprve kategorizovat selhání a poté se rozhodnout, jak dlouho budete čekat, kolik pokusů je maximálně možné a kdy je vyžadován zásah uživatele.

Níže uvedený kód a tok jsou založeny na syntetických vzorcích, které byly testovány v izolovaném prostředí. Nepředstavují záruku všech autentických dokumentů nebo efektů produktu. Před zpracováním důležitých dokumentů si prosím uschovejte originály a zkontrolujte je podle hranic a přejímacích položek v textu.

Jak to zkusit znovu poté, co úloha dokumentu ohlásí chybu? Závěr jednou větou

Nejprve klasifikujte selhání, než se rozhodnete, zda to zkusit znovu: dočasná selhání jsou omezena a stažena, problémy s oprávněním a účtem jsou zastaveny a předány uživateli a chyby vstupu jsou ponechány na uživateli, aby je odstranil.

Nejprve určete, zda opakovaný pokus vygeneruje duplicitní úlohy.

Obzvláště problematické jsou časové limity POST. Pokud klient neobdrží odpověď, neznamená to, že server nevytvořil úlohu. Pokud rozhraní nemá idempotentní klíče a nemá mechanismus dotazů na úlohy, může slepé opětovné odeslání vytvořit více úloh překladu.

Proto by se strategie opakování měla přednostně řídit smlouvou rozhraní namísto pouhého pohledu na stavový kód HTTP.

Napište počet opakování a čekací rozpočet jako čisté funkce

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

Tento kód pouze vypočítá plán opakování, ve skutečnosti nečeká a neodesílá požadavky. Pevná jedna, dvě a čtyři sekundy jsou hodnoty syntetické ukázky a nejsou obecnými servisními doporučeními.

Produkční prostředí musí také zvážit následující body:

• Retry-After vrácené serverem
• Náhodné chvění, aby se zabránilo obnovení velkého počtu úkolů současně
• Celkový termín
• Omezení počtu souběhů

Pokud čekací doba požadovaná serverem překročí místní rozpočet, měl by přestat zkoušet místo spouštění požadavku předem.

Typy chyb odpovídají různým akcím

Ukládání logických úloh a pokusů o záznamy

Uživatelská operace odpovídá logické úloze a v rámci této logické úlohy může být více pokusů. Při každém pokusu se zaprotokoluje čas zahájení, kategorie selhání a ID vzdálené úlohy. Nakonec je vybrán pouze jeden přijatý výsledek.

Výhodou je, že existuje kompletní záznam při řešení problémů s opakováním pokusů a zároveň se počet pokusů nebude přepočítávat do počtu uživatelských požadavků.

📊 Srovnání jádra

Stabilita překladu vychází z jasných vysvětlení

Při připojování k OmniDoc by měl frontend jasně sdělit uživateli aktuální stav: zda čeká, musí být znovu autorizován nebo potřebuje zkontrolovat účet. Nezobrazujte vše jako "Budova".

Uživatelé jsou ochotni čekat na úkol se stavem a ukončením, ale nejsou ochotni opakovaně klikat na tlačítko bez jakékoli zpětné vazby.

Zdroje: Python enum.

🎯 Která metoda je pro vás vhodná?

Pokud čekáte na obnovení služby

Použijte ohraničené stažení, nastavte maximální počet opakování a celkovou dobu čekání a respektujteRetry-After serveru.

Pokud máte problémy s oprávněním nebo účtem

Zastavte automatické opakování a vyzvěte uživatele k opětovné autorizaci nebo kontrole stavu účtu.

Pokud je struktura vašeho vstupního souboru nesprávná

Před odesláním nechejte uživatele opravit soubor. Neposílejte znovu stejný soubor.

Pokud je rozhraní, které voláte, POST a může vypršet časový limit

Nejprve ověřte, zda rozhraní podporuje idempotentní klíče nebo úkoly, a poté se rozhodněte, zda chcete znovu odeslat.

❓ Často kladené otázky (FAQ)

1. Lze všechny nahlášené chyby přímo zopakovat?

Nemohu. Chyby oprávnění, nedoplatky na účtu, poškozené soubory a dočasné zaneprázdněné služby by měly být řešeny samostatně. Pouze dočasné poruchy jsou vhodné pro omezený ústup.

2. Lze POST odeslat znovu přímo po vypršení časového limitu?

Nedoporučuje se znovu odesílat přímo. Pokud klient neobdrží odpověď, neznamená to, že server nevytvořil úlohu. Pokud neexistuje idempotentní klíč nebo mechanismus dotazu na úkol, může dojít k duplicitním úkolům.

3. Jak by se měl určit počet opakování a čekací doba?

Pevná jedna, dvě a čtyři sekundy jsou jen syntetické ukázky. Produkční prostředí by měla být určena kombinací Retry-After, náhodného jitteru, celkových termínů a limitů souběžnosti.

4. Ovlivní počet pokusů statistiku požadavků uživatelů?

Ne, stačí zaznamenat uživatelskou operaci jako logickou úlohu a každé opakování zaznamenat jako záznam pokusu v rámci úlohy.

📝 Shrnutí

Klíčem k opakování není zkoušet to vícekrát, ale nejprve rozlišit typ selhání a pak se rozhodnout, co dělat. Chyby, které lze odstranit, jsou omezeně opakovány a problémy, které vyžadují lidskou manipulaci, jsou včas vráceny uživatelům.

Vyzkoušejte to hned: Nahrajte dokument a začněte překládat při zachování původního rozvržení