Pāriet uz dokumentāciju
SDK

Atkārtojumi un idempotence

Kas tiek atkārtots, kas apzināti netiek un kāpēc atkārtots sūtījums nevar dublēties.

Sūtījumi

Klients katram sūtījumam pievieno Idempotency-Key (emails.send, emails.sendBatch un templates.send), ģenerētu vienreiz katram **izsaukumam** un atkārtoti izmantotu šī izsaukuma atkārtojumos. API šo atslēgu pieprasa, pirms kaut ko izsūta, tāpēc atkārtojums atskaņo sākotnējo ziņojumu, nevis nosūta otru, kamēr divi apzināti send() izsaukumi joprojām sūta divreiz. Tie ir dažādi nodomi, un tādi tie arī paliek.

Padod savu idempotencyKey, lai izstieptu šo garantiju pāri procesiem, tā ka darbs, kas avarēja un tika palaists vēlreiz, savus sūtījumus atskaņo, nevis atkārto.

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

Atvasini to no tā, kas padarīja sūtījumu nepieciešamu. Nekad no pulksteņa. Atslēgas atkārtota izmantošana ar citu ķermeni tiek noraidīta ar idempotency_key_reuse, nevis klusi atskaņota.

Viss pārējais

Katrs lasījums tiek atkārtots. Rakstīšana tiek atkārtota tikai tur, kur otrs identisks pieprasījums nevar nozīmēt neko citu kā pirmais, un sūtījums der, jo tā idempotences atslēga atkārtojumu pārvērš par atskaņojumu.

IzsaukumsAtkārtoKāpēc
Katrs lasījumsNekas nemainās.
`emails.send`, `emails.sendBatch`, `templates.send`Idempotences atslēga padara atkārtojumu par atskaņojumu.
`emails.cancel`, `emails.reschedule`Tīra nosaukta stāvokļa iestatīšana.
`threads.update`, `threads.trash`Etiķetes iestatīšana. Piemērot to divreiz ir tas pats, kas piemērot vienreiz.
`threads.snooze`, `threads.unsnooze`Pamodināšanas brīdis ir ķermenī, nevis atvasināts no pienākšanas laika.
`labels.update`, `webhooks.update`, `settings.update`, `roles.update`, `members.update`Tīra nosauktu lauku iestatīšana.
`members.grantAddress`, `rules.reorder`Piešķīrums ir upsert, un secība tiek norādīta pilnībā.
`templates.publish`Jau publicētas galvas publicēšana atgriež to nemainītu.
`templates.preview`, `rules.test`Tie attēlo vai izvērtē un neko neieraksta.
`drafts.create`, `labels.create`, `webhooks.create`, `templates.create`, `rules.create`, `roles.create`, `tempMail.create`Atkārtojums atstāj divus objektus.
`drafts.update`Nolasi id no katras rakstīšanas rezultāta, nevis izmanto atkārtoti to, ko nosūtīji.
`drafts.delete`, `labels.delete`, `webhooks.delete`, `templates.delete`, `rules.delete`, `roles.delete`, `members.remove`, `members.revokeAddress`, `tempMail.delete`, `tempMail.deleteMessage`Atkārtojums pēc pazaudētas atbildes ziņo par kļūmi darbam, kas izdevās.
`webhooks.rotateSecret`Otra rotācija anulē noslēpumu, ko atgrieza pirmais mēģinājums.
`webhooks.test`Tas nosūtītu otru sintētisko piegādi.
`emails.translate`Tas tērē modeļa izsaukumus, tāpēc atkārtojums pēc neatbildēta pieprasījuma pērk to pašu atbildi divreiz.
Katra cita rakstīšanaNosūtīts vienreiz, un par kļūmi tiek ziņots, nevis tā tiek atkārtota.

Atkāpšanās

  • Ierobežots ar klienta maxRetries, pēc noklusējuma divi papildu mēģinājumi.
  • Tikai pēc tīkla kļūmes vai 408, 500, 502, 503 vai 504. 429 tiek atkārtots tikai tad, ja tas nes Retry-After, un šis API tādu nesūta, tāpēc ātruma ierobežojums met izņēmumu uzreiz. Jebkurš cits statuss met uzreiz.
  • Eksponenciāla no pussekundes līdz astoņām, ar troksni, lai flote atveseļošanās brīdī nesinhronizētos no jauna.
  • Ritmu nosaka Retry-After abās tā formās — delay-seconds un HTTP-date. Kad serveris nosauc gaidīšanas laiku, klients gaida tieši tik ilgi, nevis atkāpjas.
  • Serveris, kas prasa ilgāk par minūti, tiek uztverts kā tāds, kas liek klientam apstāties, nevis gulēt, tāpēc kļūda tiek izmesta ar retryAfterSeconds uz tās. Atgriezties ātrāk, nekā tas prasīja, nenozīmē to ievērot.
  • Izsaucēja AbortSignal nekad netiek atkārtots. Pārtraukšana uzreiz met OpenEmailNetworkError — vai nu no pieprasījuma, vai no gaidīšanas pirms nākamā mēģinājuma.