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
Esempio di lavoro: un post riparato e un post bloccato
Esempio: in una campagna vengono preparati tre post. Per un post di testo viene segnalato un limite di velocità a breve termine; il lavoro attende fino al successivo tentativo consentito. Un post con immagine ha proporzioni errate e necessita di una nuova anteprima. Il terzo post non dispone dell'autorizzazione dell'account; In questo caso al sistema non è consentito né selezionare segretamente un altro canale né contrassegnare la pubblicazione come riuscita.
Il risultato mostra la causa, il passaggio successivo e lo stato finale per ciascun post. Un nuovo tentativo riuscito verrà riconosciuto come riparato, l'errore del supporto rimarrà bloccato fino a un nuovo rilascio e la mancanza di autorizzazione richiederà un'azione umana. La campagna quindi non è generalmente “verde” o “rossa”. Questa immagine differenziata impedisce pubblicazioni doppie e fornisce al team un elenco concreto di cose da fare.
- Ripetere automaticamente solo se l'effetto del primo tentativo è noto o può essere confrontato in modo affidabile.
- Mostra la riparazione e il blocco rimanente separatamente nello stato finale.
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.