Jeśli interfejs zgłosi błąd, spróbować ponownie? Zadania związane z dokumentacją powinny najpierw rozróżnić, które awarie można naprawić

Ponawianie prób po zgłoszeniu błędu jest powszechną praktyką, ale jeśli będziesz ponawiać próby w nieskończoność, na oślep, błędy mogą się nasilić. Błędy uprawnień, zaległości w kontach, uszkodzone pliki i tymczasowo zajęte usługi należy traktować inaczej.

Ten artykuł jest odpowiedni dla programistów i studentów produktów, którzy wykonują zadania asynchroniczne, takie jak tłumaczenie i konwersja dokumentów. Po przeczytaniu tego możesz najpierw sklasyfikować awarie, a następnie zdecydować, jak długo czekać, ile maksymalnie prób i kiedy wymagana jest interwencja użytkownika.

Poniższy kod i przepływ opierają się na próbkach syntetycznych, które zostały przetestowane w izolowanym środowisku. Nie stanowią one gwarancji autentyczności wszystkich dokumentów ani efektów produktu. Przed przystąpieniem do przetwarzania ważnych dokumentów należy zachować oryginały i zapoznać się z nimi zgodnie z granicami i pozycjami akceptacji w tekście.

Jak ponowić próbę, gdy zadanie dokumentu zgłosi błąd? Wniosek w jednym zdaniu

Najpierw sklasyfikowaj awarię, zanim podejmiesz decyzję o ponownej próbie: tymczasowe awarie są ograniczane i wycofywane, problemy z uprawnieniami i kontem są zatrzymywane i przekazywane użytkownikowi, a błędy wejściowe pozostawia się użytkownikowi do naprawienia.

Najpierw ustal, czy ponowna próba spowoduje wygenerowanie zduplikowanych zadań.

Przekroczenia limitu czasu testu POST są szczególnie kłopotliwe. Jeśli klient nie otrzyma odpowiedzi, nie oznacza to, że serwer nie utworzył zadania. Jeśli interfejs nie ma kluczy idempotentnych i nie ma mechanizmu zapytań o zadania, ponowne wysyłanie na ślepo może spowodować utworzenie wielu zadań tłumaczeniowych.

Dlatego strategia ponawiania powinna najpierw postępować zgodnie z umową interfejsu, a nie tylko patrzeć na kod stanu HTTP.

Zapisz liczbę powtórzeń i budżet oczekujący jako czyste funkcje

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

Ten kod oblicza jedynie plan ponownych prób, tak naprawdę nie czeka i nie wysyła żądań. Stałe jedna, dwie i cztery sekundy to wartości syntetycznej demonstracji i nie stanowią ogólnych zaleceń serwisowych.

Środowiska produkcyjne muszą również wziąć pod uwagę następujące kwestie:

• Retry-After zwrócony przez serwer
• Losowe drgania, aby uniknąć wznawiania dużej liczby zadań jednocześnie
• Ogólny termin
• Limit liczby współbieżności

Jeśli czas oczekiwania wymagany przez serwer przekracza lokalny budżet, powinien on przerwać ponawianie próby, zamiast inicjować żądanie z wyprzedzeniem.

Typy błędów odpowiadają różnym akcjom

Zapisywanie logów zadań logicznych i prób

Każda operacja użytkownika odpowiada zadaniu logicznemu, a w tej logice może być wiele prób. Każda próba rejestruje czas rozpoczęcia, kategorię awarii oraz identyfikator zdalnego zadania. Ostatecznie wybierany jest tylko jeden wynik, który przeszedł akceptację.

Zaletą tego podejścia jest to, że istnieje pełny rekord podczas rozwiązywania problemów z ponownym próbowaniem, a liczba prób nie jest błędnie liczona jako liczba żądań użytkownika.

📊 Porównanie rdzenia

Stabilność doświadczenia tłumaczenia wynika z jasnych wyjaśnień

Podczas łączenia z OmniDoc frontend powinien jasno informować użytkowników o aktualnym statusie: czy czekają, potrzebują ponownego autoryzowania, czy muszą sprawdzić swoje konto. Nie wyświetlaj wszystkich sytuacji jako "Generujące".

Użytkownicy są gotowi czekać na określone, wychodzące zadanie, ale nie chcą wielokrotnie klikać przycisku, który nie daje żadnej informacji zwrotnej.

Źródła: Python enum.

🎯 Która metoda ci odpowiada?

Jeśli czekasz na wznowienie serwisu

Stosuj ograniczony odwrót, ustaw maksymalną liczbę i całkowity czas oczekiwania oraz szanujRetry-After serwera.

Jeśli napotkasz problemy z uprawnieniami lub kontem

Zatrzymaj automatyczne ponowne próby, poproś użytkowników o ponowną autoryzację lub sprawdź status konta.

Jeśli struktura pliku wejściowego jest nieprawidłowa

Proś użytkowników o naprawę plików przed przesłaniem i nie wysyłaj tego samego pliku ponownie.

Jeśli interfejs, który wywołujesz, to POST i może wygasnąć,

Najpierw potwierdzić, czy interfejs obsługuje klucze idempotentne lub zapytania zadań, a następnie zdecyduj, czy wysłać je ponownie.

❓ Najczęściej zadawane pytania (FAQ)

1. Czy wszystkie błędy można powtarzać bezpośrednio?

Nie, nie możesz. Błędy uprawnień, nadpłaty konta, uszkodzone pliki oraz tymczasowe zajęcie usługą powinny być rozpatrywane osobno; tylko tymczasowe awarie nadają się do ograniczania unikania.

2. Czy mogę ponownie opublikować po upływie czasu POST?

Nie zaleca się bezpośredniego ponownego publikowania. Brak odpowiedzi klienta nie oznacza, że serwer nie stworzył zadań. Bez kluczy idempotencji lub mechanizmów zapytań o zadania mogą wystąpić duplikaty zadań.

3. Jak należy ustalać liczbę powtórek i czas oczekiwania?

Stałe sekundy jeden, dwa i cztery służą tylko do demonstracji syntezy. Środowisko produkcyjne powinno być określane przez połączenie Retry-After, losowego jittera, ogólnego czasu odcięcia oraz ograniczeń współbieżności.

4. Czy liczba prób wpłynie na statystyki zgłoszeń użytkowników?

Nie, po prostu zapisz jedną operację użytkownika jako logiczne zadanie i każdą próbę jako próbę w ramach tego zadania.

📝 Podsumowanie

Kluczem do ponownego próbowania nie jest próba wielokrotnie, ale najpierw zidentyfikowanie rodzaju porażki, zanim zdecydujesz, co zrobić. Błędy możliwe do odzyskania są ograniczane i ponownie próbowane, a problemy wymagające ludzkiej obsługi są natychmiast zwracane użytkownikom.

Doświadczenie teraz: Prześlij dokument, aby zacząć tłumaczyć, zachowując oryginalne formatowanie