Oriphiel OpenClaw vodič
Retry, dead-letter i reconciliation
Kako razlikovati prolaznu i trajnu grešku, kontrolirati ponovne pokušaje te uskladiti lokalno stanje s vanjskim sustavom.
Odgovor ukratko
Retry pomaže samo kod prolazne greške i mora biti idempotentan; trajna validacijska ili autentikacijska greška ide u vidljiv dead-letter proces.
Ključne odluke
- Koja je greška retryable
- Koliki je exponential backoff
- Kada item ide u dead-letter
- Koji sustav je izvor istine
Provedba korak po korak
Cilj ove lekcije je Kako razlikovati prolaznu i trajnu grešku, kontrolirati ponovne pokušaje te uskladiti lokalno stanje s vanjskim sustavom. Korake treba provoditi redom i svaki potvrditi prije širenja opsega.
Preporučeni redoslijed
- Klasificirati error codeove
- Dodati limit pokušaja i jitter
- Prikazati dead-letter queue administratoru
- Periodično usporediti lokalne i provider statuse
Praktičan primjer
SMTP 421 ide u odgođeni retry s backoffom, 535 odmah zaustavlja mailbox konfiguraciju, a admin vidi posljednju grešku i pogođene iteme.
Kontrolna lista prije nastavka
Ova provjera odvaja završenu implementaciju od postavke koja samo izgleda dovršeno.
Provjerite
- AUTH greška se ne pokušava stotinama puta
- 429 poštuje Retry-After
- Svaki pokušaj ima correlation ID
- Reconciliation ne šalje poruku ponovno
Najčešće pogreške i rizici
Rizike treba provjeriti prije povećanja prometa, automatizacije ili ovlasti sustava.
Na što treba paziti
- Beskonačni retry puni queue
- Sve greške tretiraju se jednako
- Item se ručno briše bez zapisa
- Lokalni sent status postoji prije potvrde providera
Mjerenje rezultata
Učinak se procjenjuje kroz mali skup metrika koje su povezane s ciljem lekcije i stvarnim poslovnim ishodom.
Metrike koje imaju smisla
- Retry rate
- Dead-letter count
- Reconciled discrepancies
- Mean time to resolution
Česta pitanja
Koji je prvi korak za temu „Retry, dead-letter i reconciliation”?
Klasificirati error codeove Prije nastavka potvrdite odluku: Koja je greška retryable
Kako provjeriti da je provedba uspješna?
AUTH greška se ne pokušava stotinama puta Nakon toga pratite metriku: Retry rate.
Koju pogrešku treba prvo spriječiti?
Beskonačni retry puni queue Problem ispravite prije automatizacije ili povećanja budžeta.
Službeni i stručni izvori
Sučelja, pravila i preporuke mogu se mijenjati. Prije produkcijske izmjene provjerite aktualnu dokumentaciju.
Primijenite lekciju na stvarni projekt
Pošaljite postojeću konfiguraciju, cilj i problem koji želite riješiti. Dobit ćete prijedlog sljedećeg tehničkog ili operativnog koraka.