Probeer het opnieuw als de interface een fout meldt? Documentatietaken moeten eerst onderscheiden welke fouten kunnen worden hersteld

Het is gebruikelijk om het opnieuw te proberen nadat er een fout is gemeld, maar als u het voor onbepaalde tijd opnieuw probeert, kunnen de problemen groter worden. Toestemmingsfouten, betalingsachterstanden, beschadigde bestanden en tijdelijk drukke services moeten op een andere manier worden afgehandeld.

Dit artikel is geschikt voor ontwikkelaars en productstudenten die asynchrone taken uitvoeren, zoals het vertalen en converteren van documenten. Nadat u dit heeft gelezen, kunt u eerst de fouten categoriseren en vervolgens beslissen hoe lang u moet wachten, hoeveel pogingen maximaal en wanneer tussenkomst van de gebruiker vereist is.

De onderstaande code en stroom zijn gebaseerd op synthetische monsters die in een geïsoleerde omgeving zijn getest. Ze vormen geen garantie voor alle authentieke documenten of producteffecten. Bewaar de originelen voordat u belangrijke documenten verwerkt en controleer ze volgens de grenzen en acceptatie-items in de tekst.

Hoe kan ik het opnieuw proberen nadat de documenttaak een fout meldt? Conclusie in één zin

Classificeer eerst de fout voordat u besluit of u het opnieuw wilt proberen: tijdelijke fouten worden begrensd en teruggetrokken, toestemmings- en accountproblemen worden gestopt en overgedragen aan de gebruiker, en invoerfouten worden aan de gebruiker overgelaten om op te lossen.

Bepaal eerst of opnieuw proberen dubbele taken zal genereren.

POST-time-outs zijn bijzonder lastig. Als de client geen antwoord ontvangt, betekent dit niet dat de server geen taak heeft aangemaakt. Als de interface geen idempotente sleutels heeft en geen mechanisme voor het opvragen van taken, kan het blind opnieuw verzenden meerdere vertaaltaken creëren.

Daarom moet de strategie voor opnieuw proberen eerst het interfacecontract volgen in plaats van alleen naar de HTTP-statuscode te kijken.

Schrijf het aantal keren en het wachtbudget als pure functies

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

Deze code berekent alleen het plan voor opnieuw proberen, wacht niet daadwerkelijk en verzendt geen verzoeken. De vaste één, twee en vier seconden zijn de waarden van de synthetische demonstratie en zijn geen algemene service-aanbevelingen.

Productieomgevingen moeten ook rekening houden met de volgende punten:

• Retry-After geretourneerd door de server
• Willekeurige jitter om te voorkomen dat een groot aantal taken tegelijkertijd wordt hervat
• Algemene deadline
• Beperking van het aantal gelijktijdigheden

Als de door de server vereiste wachttijd het lokale budget overschrijdt, moet deze stoppen met het opnieuw proberen in plaats van het verzoek vooraf te initiëren.

Fouttypen komen overeen met verschillende acties

Logs van logische taken en poginglogs opslaan

Elke gebruikersbewerking komt overeen met een logische taak, en er kunnen meerdere pogingen zijn onder deze logica. Elke poging registreert de starttijd, de faalcategorie en de externe taak-ID. Uiteindelijk wordt slechts één resultaat geselecteerd dat door de acceptatie is gekomen.

Het voordeel van deze aanpak is dat er een volledig overzicht is bij het oplossen van herpogingen, en het aantal pogingen wordt niet verkeerd geteld als het aantal gebruikersverzoeken.

📊 Kernvergelijking

De stabiliteit van de vertaalervaring komt voort uit duidelijke verklaringen

Bij het verbinden met OmniDoc moet de frontend gebruikers duidelijk informeren over de huidige status: of ze wachten, herautorisatie nodig hebben of hun account moeten controleren. Toon niet alle situaties als "Genererend."

Gebruikers zijn bereid te wachten op een opgegeven taak buiten de uitgang, maar zijn niet bereid om herhaaldelijk op een knop te klikken die geen feedback geeft.

Bronnen: Python enum.

🎯 Welke methode past bij jou?

Als je wacht tot de dienst wordt hervat

Gebruik begrensde terugtrekking, stel het maximale aantal en de totale wachttijd in, en respecteer deRetry-After van de server.

Als je problemen met toestemmingen of accounts tegenkomt.

Stop automatische herkansingen, vraag gebruikers om opnieuw te autoriseren of de status van het account te controleren.

Als je invoerbestandsstructuur onjuist is

Vraag gebruikers om bestanden te repareren voordat ze het indienen, en stuur hetzelfde bestand niet opnieuw.

Als de interface die je aanroept POST is en mogelijk een timeout heeft,

Eerst bevestig of de interface idempotente sleutels of taakqueries ondersteunt, en beslis vervolgens of je deze opnieuw wilt verzenden.

❓ Veelgestelde Vragen (FAQ)

1. Kunnen alle fouten direct opnieuw worden geprobeerd?

Nee, dat kan niet. Toestemmingsfouten, overbetalingen van accounts, corrupte bestanden en tijdelijke service bezet moeten apart worden afgehandeld; alleen tijdelijke storingen zijn geschikt voor begrensde vermijding.

2. Kan ik opnieuw posten nadat een POST-timeout is afgelopen?

Het wordt niet aanbevolen om direct opnieuw te plaatsen. Het gebrek aan respons van de client betekent niet dat de server geen taken heeft aangemaakt. Zonder idempotentiesleutels of taakquerymechanismen kunnen dubbele taken optreden.

3. Hoe moet het aantal herpogingen en wachttijden worden bepaald?

De vaste één, twee en vier seconden zijn alleen voor de synthesedemonstratie. De productieomgeving moet worden bepaald door Retry-After, willekeurige jitter, totale cutoff-tijd en gelijktijdige beperkingen te combineren.

4. Zal het aantal pogingen de statistieken van gebruikersverzoeken beïnvloeden?

Nee, registreer gewoon één gebruikersbewerking als een logische taak en elke herpoging als een poging onder die taak.

📝 Samenvatting

De sleutel tot opnieuw proberen is niet meerdere keren proberen, maar eerst het type mislukking identificeren voordat je beslist wat je doet. Herstelbare fouten worden beperkt en opnieuw geprobeerd, en kwesties die menselijke behandeling vereisen, worden direct teruggegeven aan gebruikers.

Ervaar nu: upload je document om te beginnen met vertalen, waarbij je de originele opmaak behoudt