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.send_batch, templates.send dhe broadcasts.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 idempotency_key-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ë.
invoice_id = 'inv_4192' client.emails.send( {'from': sender, 'to': recipient, 'subject': subject, 'text': text}, idempotency_key=f'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.send_batch, templates.send dhe broadcasts.send | Po | Një çelës idempotence e kthen përsëritjen në riluajtje. |
| emails.cancel, emails.reschedule, broadcasts.cancel, forms.publish, forms.pause, forms.resume, forms.approve_submission, account.accept_invitation dhe account.decline_invitation | Po | Një vendosje e pastër e një gjendjeje të emërtuar. |
| threads.update, threads.trash dhe threads.restore | 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, domains.update, contacts.update, audiences.update, keys.update, emails.update, forms.update, branding.update, chats.rename, threads.update_note, domains.update_address, domains.update_address_forward, account.set_email_notification, account.set_push_muted, app_host.set dhe workspaces.set_active | Po | Një vendosje e pastër e fushave të emërtuara. |
| members.grant_address, members.grant_domain, rules.reorder dhe threads.reorder_notes | Po | Dhënia e së drejtës është një upsert, dhe renditja jepet e plotë. |
| templates.publish, imports.start | Po | Publikimi i një head-i tashmë të publikuar, ose nisja e një importi që ka nisur tashmë, e kthen atë të pandryshuar. |
| templates.preview, templates.render, broadcasts.preview dhe rules.test | Po | Ato renderojnë, numërojnë ose vlerësojnë dhe nuk shkruajnë asgjë. |
| domains.verify, app_host.verify | Po | Një kontroll i përsëritur nuk ndryshon asgjë përveç kohës së kontrollit. |
| contacts.save, contacts.set_audiences, contacts.remove_photo, contacts.block, contacts.unblock, contacts.delete_many, keys.revoke, account.remove_photo, branding.remove_image, domains.remove_logo, domains.remove_logo_certificate, domains.remove_address_photo, app_host.delete, files.revoke_link, files.revoke_all_links dhe subscriptions.move | Po | Secila deklaron rezultatin përfundimtar, ndaj një thirrje e dytë lë atë që la e para. |
| audiences.add_contact, audiences.add_contacts, audiences.remove_contacts, audiences.import_contacts, suppressions.add, domains.create_address dhe senders.research | Po | Një përsëritje e gjen punën e thirrjes së parë të kryer tashmë dhe e raporton atë në vend që ta bëjë dy herë. |
| contacts.set_photo, imports.upload_chunk, account.set_photo, branding.upload_image, domains.set_logo, domains.set_logo_certificate dhe domains.set_address_photo | Po | Bajtet e dërguara sërish zëvendësojnë atë që ruajti përpjekja e parë. |
| drafts.create, labels.create, webhooks.create, templates.create, rules.create, roles.create, temp_mail.create, files.upload, templates.design dhe forms.design | 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.revoke_address, temp_mail.delete dhe temp_mail.delete_message | Jo | Një riprovë pas një përgjigjeje të humbur raporton dështim për punë që pati sukses. |
| webhooks.rotate_secret | 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. |
| webhooks.replay_delivery | Jo | Do ta dërgonte ngjarjen te marrësi juaj për herë të dytë. |
| 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. |
| emails.compose, emails.rewrite dhe emails.suggest_subject | Jo | Çdo përpjekje shpenzon një veprim tjetër AI dhe kthehet me një përgjigje tjetër. |
| Çdo thirrje tjetër | Jo | Dërgohet një herë, dhe një dështim raportohet në vend që të përsëritet. |
forms.update riprovohet edhe me expectedUpdatedAt, ndaj një riprovim pas një përgjigjeje të humbur mund të kthehet me 409 version_conflict, sepse përpjekja e parë kaloi. Lexojeni formularin para se të provoni sërish.
client.raw.request riprovon një GET dhe çdo gjë tjetër e dërgon një herë, përveç nëse jepni repeatable=True.
Backoff-i
- E kufizuar nga
max_retrieste klienti, me parazgjedhje dy përpjekje shtesë. - Vetëm pas një dështimi rrjeti ose një
408,500,502,503a504. Një429riprovohet vetëm kur mbart njëRetry-After, dhe kjo API nuk dërgon të tillë, ndaj një kufi shpejtësie ngre gabim menjëherë. Çdo status tjetër ngre 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-Afternë 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
retry_after_secondsmbi të. Të kthehesh më herët se sa kërkoi ai nuk do të thotë ta respektosh. timeoutkufizon çdo përpjekje, kështu që një thirrje që i përdor të dy riprovimet e saj mund të zgjasë tre afate kohore plus pritjet mes tyre.- Anulimi i një thirrjeje të
AsyncOpenEmailnuk riprovohet kurrë. Anulimi përhapet menjëherë, nga kërkesa ose nga pritja para përpjekjes së radhës.