SDK

Riprovat dhe idempotenca

Çfarë riprovohet, çfarë nuk riprovohet me qëllim dhe pse një dërgim i riprovuar nuk mund të dyfishohet.

Dërgimet

Klienti i bashkëngjit një Idempotency-Key çdo dërgimi (emails.send, emails.sendBatch dhe templates.send), të gjeneruar një herë për çdo **thirrje** dhe të ripërdorur nga riprovat e asaj thirrjeje. API-ja e rezervon atë çelës përpara se të nisë çfarëdo gjëje, ndaj një riprovë e riluan mesazhin origjinal në vend që të dërgojë një të dytë, ndërsa dy thirrje të qëllimshme send() dërgojnë prapëseprapë dy herë. Këto janë qëllime të ndryshme dhe mbeten të ndryshme.

Jepni idempotencyKey-n tuaj për ta shtrirë atë garanci përtej proceseve, që një punë e cila u rrëzua dhe u ekzekutua sërish t'i riluajë dërgimet e veta në vend që t'i përsërisë.

idempotency.ts

await openemail.emails.send(message, { idempotencyKey: `invoice:${invoice.id}` })

Nxirreni nga ajo që e bëri të nevojshëm dërgimin. Kurrë nga një orë. Ripërdorimi i një çelësi me një trup tjetër refuzohet me idempotency_key_reuse, në vend që të riluhet në heshtje.

Gjithçka tjetër

Çdo lexim riprovohet. Një shkrim riprovohet vetëm aty ku një kërkesë e dytë identike nuk mund të nënkuptojë asgjë ndryshe nga e para, dhe një dërgim e plotëson këtë kusht sepse çelësi i tij i idempotencës e kthen përsëritjen në riluajtje.

Thirrja	Riprovohet	Pse
Çdo lexim	Po	Nuk ndryshon asgjë.
`emails.send`, `emails.sendBatch`, `templates.send`	Po	Një çelës idempotence e kthen përsëritjen në riluajtje.
`emails.cancel`, `emails.reschedule`	Po	Një vendosje e pastër e një gjendjeje të emërtuar.
`threads.update`, `threads.trash`	Po	Një vendosje etiketash. Ta zbatosh dy herë është njësoj si ta zbatosh një herë.
`threads.snooze`, `threads.unsnooze`	Po	Çasti i zgjimit ndodhet në trup, nuk nxirret nga koha e mbërritjes.
`labels.update`, `webhooks.update`, `settings.update`, `roles.update`, `members.update`	Po	Një vendosje e pastër e fushave të emërtuara.
`members.grantAddress`, `rules.reorder`	Po	Dhënia e së drejtës është një upsert, dhe renditja jepet e plotë.
`templates.publish`	Po	Publikimi i një head-i tashmë të publikuar e kthen atë të pandryshuar.
`templates.preview`, `rules.test`	Po	Ato renderojnë ose vlerësojnë dhe nuk shkruajnë asgjë.
`drafts.create`, `labels.create`, `webhooks.create`, `templates.create`, `rules.create`, `roles.create`, `tempMail.create`	Jo	Një riprovë lë dy objekte.
`drafts.update`	Jo	Lexojeni id-në nga rezultati i çdo shkrimi, në vend që të ripërdorni atë që dërguat.
`drafts.delete`, `labels.delete`, `webhooks.delete`, `templates.delete`, `rules.delete`, `roles.delete`, `members.remove`, `members.revokeAddress`, `tempMail.delete`, `tempMail.deleteMessage`	Jo	Një riprovë pas një përgjigjeje të humbur raporton dështim për punë që pati sukses.
`webhooks.rotateSecret`	Jo	Një rrotullim i dytë e bën të pavlefshëm sekretin që ktheu përpjekja e parë.
`webhooks.test`	Jo	Do të dërgonte një dërgesë të dytë sintetike.
`emails.translate`	Jo	Harxhon thirrje modeli, ndaj një riprovë pas një kërkese pa përgjigje e blen dy herë të njëjtën përgjigje.
Çdo shkrim tjetër	Jo	Dërgohet një herë, dhe një dështim raportohet në vend që të përsëritet.

Backoff-i

E kufizuar nga maxRetries te klienti, me parazgjedhje dy përpjekje shtesë.
Vetëm pas një dështimi rrjeti ose një 408, 500, 502, 503 a 504. Një 429 riprovohet vetëm kur mbart një Retry-After, dhe kjo API nuk dërgon të tillë, ndaj një kufi shpejtësie hedh gabim menjëherë. Çdo status tjetër hedh gabim në çast.
Eksponenciale nga gjysmë sekonde deri në tetë, me jitter, që një flotë të mos risinkronizohet në çastin e rimëkëmbjes.
E ritmuar nga Retry-After në secilën prej formave të tij, delay-seconds dhe HTTP-date. Kur serveri cakton një pritje, klienti pret pikërisht aq, në vend që të bëjë backoff.
Një server që kërkon më shumë se një minutë trajtohet sikur i thotë klientit të ndalojë, jo të flerë, ndaj gabimi ngrihet me retryAfterSeconds mbi të. Të kthehesh më herët se sa kërkoi ai nuk do të thotë ta respektosh.
Një AbortSignal i thirrësit nuk riprovohet kurrë. Ndërprerja hedh menjëherë një OpenEmailNetworkError, qoftë nga kërkesa, qoftë nga pritja para përpjekjes tjetër.