Gli errori vengono classificati in base a causa ed effetto
Un timeout di rete, un limite di velocità, un token OAuth scaduto, un supporto non valido e una ricerca facoltativa vuota richiedono risposte diverse. Un comune messaggio di "errore" non è sufficiente per la riparazione e il processo decisionale dell'utente.
Inoltre, si valuta se il risultato è sicuramente sconosciuto, chiaramente non eseguito o tecnicamente inutilizzabile. Questa distinzione impedisce la duplicazione di azioni esterne.
- transitorio: riprovare può essere sicuro
- auth: utente o riconnessione richiesta
- rate_limit: backoff e tentativo successivo
- media_invalid: modifica la risorsa
- optional_missing: salta documentato
- Unknown_external_state: verifica prima
La politica di ripristino viene corretta prima dell'errore
Per ogni azione viene definito quanto spesso può essere ripetuta, quali errori possono essere ritentati, se è consentito cambiare fornitore e quale limite di costo superiore si applica. Ciò significa che il sistema non decide spontaneamente in merito a nuovi rischi in uno stato di emergenza.
Un fallback deve essere tecnicamente equivalente e approvato. Una ricerca di titoli può spostarsi da una fonte a un'altra quando vengono controllate licenza, provenienza e pertinenza. Una pubblicazione non può essere eseguita in modo invisibile attraverso un altro account o canale.
Un singolo canale interrotto rimane isolato
Un lavoro multicanale è costituito da contributi indipendenti con precursori comuni. Se X nega un'autorizzazione, Instagram e Pinterest possono ancora essere pronti. Lo stato complessivo diventa quindi PARZIALE o DEGRADATO invece di SUCCESSO o FALLIMENTO completo.
Gli errori di sicurezza comuni sono diversi. Un'area di lavoro errata, una mancanza di approvazione generale o un limite di credito superato interrompono tutti i passaggi dipendenti.
Di conseguenza le riparazioni devono rimanere visibili
Il completamento conta separatamente i successi normali, i passaggi riparati automaticamente, i salti opzionali e i bloccanti. Di ogni riparazione resta tracciabile il primo errore, la strategia utilizzata ed il risultato finale.
Questa trasparenza ha vantaggi pratici: se i fallback si accumulano presso un fornitore, questo è un problema operativo. Se la musica opzionale viene saltata regolarmente, forse il flusso di lavoro dovrebbe essere pianificato senza musica per impostazione predefinita.
Testare specificamente i guasti noti
L’autoguarigione non può essere dimostrata solo attraverso prove del percorso felice. Un gate di produzione simula almeno le classi di errore conosciute e controlla se lo stato, i costi e le azioni successive sono corretti.
- 429 con Riprova dopo
- ricerca di titoli vuoti con fallback qualificato
- nessun brano musicale opzionale adatto
- mezzo obbligatorio mancante per un canale
- singolo fornitore degradato
- È necessaria la riconnessione OAuth
- stato di pubblicazione esterna poco chiaro senza doppio tentativo
FAQ
Una corsa con riparazione automatica ha SUCCESSO?
Può essere tecnicamente completato, ma dovrebbe mostrare la riparazione separatamente. Uno stato finale neutro con recupero visibile è più onesto di un verde indifferenziato.
Quando il fallback di un provider è sicuro?
Se l'azione è ripetibile, il risultato esterno evidentemente non viene eseguito, il sostituto viene liberato ed è tecnicamente e giuridicamente qualificato.