Se l'interfaccia segnala un errore, riprovare? Le attività di documentazione dovrebbero innanzitutto distinguere quali errori possono essere ripristinati

Riprovare dopo che è stato segnalato un errore è una pratica comune, ma se si riprova indiscriminatamente per un tempo indefinito, i problemi possono essere amplificati. Errori di autorizzazione, account arretrati, file danneggiati e servizi temporanei occupati dovrebbero essere gestiti diversamente.

Questo articolo è adatto a sviluppatori e studenti di prodotti che svolgono attività asincrone come la traduzione e la conversione di documenti. Dopo aver letto questo, puoi prima classificare gli errori e poi decidere quanto tempo attendere, quanti tentativi al massimo e quando è richiesto l'intervento dell'utente.

Il codice e il flusso riportati di seguito si basano su campioni sintetici testati in un ambiente isolato. Non rappresentano una garanzia di tutti i documenti autentici o degli effetti del prodotto. Si prega di conservare gli originali prima di elaborare documenti importanti e di rivederli in base ai limiti e agli elementi di accettazione nel testo.

Come riprovare dopo che l'attività del documento ha segnalato un errore? Conclusione di una frase

Classificare innanzitutto l'errore prima di decidere se riprovare: gli errori temporanei vengono limitati e ritirati, i problemi di autorizzazione e account vengono interrotti e consegnati all'utente e gli errori di input vengono lasciati all'utente per essere corretti.

Determina innanzitutto se il nuovo tentativo genererà attività duplicate.

I timeout POST sono particolarmente problematici. Se il client non riceve una risposta, non significa che il server non ha creato un'attività. Se l'interfaccia non dispone di chiavi idempotenti e di un meccanismo di query delle attività, il nuovo invio cieco può creare più attività di traduzione.

Pertanto, la strategia dei nuovi tentativi dovrebbe seguire preferibilmente il contratto dell'interfaccia invece di limitarsi a guardare il codice di stato HTTP.

Scrivi il numero di volte e il budget di attesa come funzioni pure

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

Questo codice calcola solo il piano di tentativi, non attende effettivamente e non invia richieste. I secondi fissi, due e quattro sono i valori della dimostrazione sintetica e non sono raccomandazioni generali di servizio.

Gli ambienti di produzione devono inoltre considerare i seguenti punti:

• Retry-After restituito dal server
• Jitter casuale per evitare di riprendere un gran numero di attività contemporaneamente
• Scadenza complessiva
• Limite al numero di concorrenti

Se il tempo di attesa richiesto dal server supera il budget locale, dovrebbe interrompere i tentativi invece di avviare la richiesta in anticipo.

I tipi di errore corrispondono a diverse azioni

Salva attività logiche e tenta di registrare

Un'operazione utente corrisponde a un'attività logica e possono esserci più tentativi nell'ambito di questa attività logica. Per ogni tentativo vengono registrati l'ora di inizio, la categoria di errore e l'ID dell'attività remota. Alla fine, viene selezionato un solo risultato accettato.

Il vantaggio di ciò è che esiste un record completo durante la risoluzione dei problemi relativi ai nuovi tentativi e, allo stesso tempo, il numero di tentativi non verrà calcolato erroneamente nel numero di richieste dell'utente.

📊 Confronto fondamentale

La stabilità dell'esperienza di traduzione deriva da spiegazioni chiare

Quando ci si connette a OmniDoc, il front-end dovrebbe indicare chiaramente all'utente lo stato corrente: se è in attesa, deve essere nuovamente autorizzato o deve controllare l'account. Non visualizzare tutto come "Edificio".

Gli utenti sono disposti ad attendere un'attività con stato e uscita, ma non sono disposti a fare clic ripetutamente su un pulsante senza alcun feedback.

Riferimenti: Python enum.

🎯Quale metodo è adatto a te?

Se stai aspettando il ripristino del servizio

Utilizza il backoff limitato, imposta il numero massimo di volte e il tempo di attesa totale e rispetta ilRetry-After del server.

Se hai problemi con i permessi o con l'account

Interrompi i tentativi automatici e chiedi all'utente di autorizzare nuovamente o verificare lo stato dell'account.

Se la struttura del file di input è sbagliata

Consentire all'utente di riparare il file prima di inviarlo. Non inviare nuovamente lo stesso file.

Se l'interfaccia richiamata è POST e potrebbe andare in timeout

Verificare innanzitutto se l'interfaccia supporta chiavi idempotenti o query di attività, quindi decidere se inviare nuovamente.

❓ Domande frequenti (FAQ)

1. È possibile riprovare direttamente tutti gli errori segnalati?

Non posso. Gli errori di autorizzazione, gli account arretrati, i file danneggiati e i servizi temporanei occupati devono essere gestiti separatamente. Solo i guasti temporanei sono adatti per il backoff limitato.

2. È possibile inviare nuovamente il POST direttamente allo scadere del tempo?

Non è consigliabile inviare nuovamente direttamente. Se il client non riceve una risposta, non significa che il server non ha creato un'attività. Se non è presente una chiave idempotente o un meccanismo di query delle attività, potrebbero verificarsi attività duplicate.

3. Come dovrebbe essere determinato il numero di tentativi e il tempo di attesa?

I secondi fissi uno, due e quattro sono solo dimostrazioni sintetiche. Gli ambienti di produzione dovrebbero essere determinati con una combinazione di Retry-After, jitter casuale, scadenze generali e limiti di concorrenza.

4. Il numero di tentativi influenzerà le statistiche delle richieste degli utenti?

No, è sufficiente registrare un'operazione dell'utente come attività logica e registrare ogni tentativo come record di tentativi nell'attività.

📝 Riepilogo

La chiave per riprovare non è riprovare più volte, ma distinguere prima il tipo di errore e poi decidere cosa fare. Gli errori che possono essere ripristinati vengono ritentati in modo limitato e i problemi che richiedono la gestione umana vengono restituiti agli utenti in modo tempestivo.

Provalo subito: carica il documento per iniziare la traduzione, mantenendo il layout originale