Innanzitutto chiarire qual è l'errore
HTTP 429 significa che un provider non accetterà un'altra richiesta in questo momento. Ciò è diverso da un token OAuth scaduto, da un'autorizzazione mancante, da un supporto non valido o da un errore tecnico della piattaforma. Solo gli errori classificati correttamente ricevono la riparazione adeguata.
La risposta può contenere un suggerimento per riprovare dopo. Se manca, il sistema utilizza un backoff esponenziale limitato con diffusione casuale. Ciò significa che i lavori paralleli non si riavviano contemporaneamente e generano immediatamente il limite successivo.
Prima di riprovare è necessario chiarire l’idempotenza
In caso di interruzione della connessione non sempre si sa se il fornitore ha già accettato il contributo. Un tentativo cieco può quindi pubblicare due volte. Ogni lavoro di pubblicazione necessita di un ID interno stabile e, se supportato, di una chiave di idempotenza o di un riferimento al provider.
Se il risultato non è chiaro, il lavoro passa a uno stato come SCONOSCIUTO o VERIFICA. Il sistema controlla innanzitutto lo stato del fornitore e i riferimenti esistenti. Può essere ripetuto solo un tentativo chiaramente non effettuato.
Il backoff rimane limitato e osservabile
Un piano di tentativi sensato prevede un numero massimo di tentativi, un tempo di attesa massimo e una fine. Ogni tentativo registra la classe dell'errore, l'ora e la scadenza successiva. Le ripetizioni infinite nascondono un difetto e possono comportare costi aggiuntivi.
Dopo estenuanti tentativi, il post non verrà contrassegnato come riuscito. Rimane bloccato o viene riassegnato all'azione dell'utente. Altre piattaforme possono continuare a funzionare purché il loro lavoro sia indipendente.
- Rispetta Retry-After
- Utilizza il backoff esponenziale con jitter
- limitare il numero massimo di tentativi
- nessuna ripetizione se il risultato esterno non è chiaro
- isolare per piattaforma
- Rendi visibili le riparazioni alla fine
Il fallback del provider non è sempre possibile
Per i media stock o l'elaborazione generativa, un altro fornitore approvato può soddisfare lo stesso scopo tecnico. Tuttavia, con la pubblicazione social vera e propria, l'account di destinazione è legato a una connessione alla piattaforma. Una modifica non può essere pubblicata inosservata tramite un altro account o strumento.
Il fallback viene quindi valutato in base al tipo di azione. Una ricerca di immagini vuota può passare a una seconda fonte qualificata. Un diritto OAuth mancante richiede una riconnessione. Una proporzione non valida richiede la regolazione dei contenuti multimediali.
Breve runbook per le operazioni
Un team dovrebbe avere un processo prestabilito per gli errori di pubblicazione ricorrenti. Riduce le riparazioni spontanee e rende comprensibili i rapporti sullo stato.
- Mostra la classe di errore e il canale interessato
- Controlla lo stato esterno e l'ID del provider
- determinare un nuovo tentativo sicuro o un'azione specifica dell'utente
- continuare lavori indipendenti
- Al termine, sincronizza la coda e il calendario
- Escludi duplicati tra ID interni ed esterni
FAQ
È opportuno ritentare immediatamente un 429?
No. Dovresti attendere l'avviso del fornitore o un backoff limitato. I tentativi paralleli istantanei spesso riducono il limite.
Il lavoro complessivo può interrompersi a causa di una piattaforma?
Solo se manca un requisito comune rilevante per la sicurezza. Un bug della piattaforma isolato non dovrebbe bloccare altri post indipendenti.