Kalo te dokumentacioni
Ruby

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** si oe- plus një UUID të rastësishëm, 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: tuajin për ta shtrirë këtë garanci mes proceseve, që një punë në sfond që u rrëzua dhe u ekzekutua sërish t’i riluajë dërgimet e saj në vend që t’i përsërisë. Një riluajtje përgjigjet me replayed true dhe me mesazhin e ruajtur siç është tani.

idempotency.rb
invoice_id = "inv_2026_09_4192" sent = client.emails.send(  from: "[email protected]",  to: "[email protected]",  subject: "Your September invoice",  text: "Invoice attached.",  idempotency_key: "invoice:#{invoice_id}") puts sent[:id], sent[:replayed]

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 një 422 idempotency_key_reuse në vend që të riluhet në heshtje. Një çelës ka nga 1 deri në 255 karaktere: shkronja, shifra, _, ., : ose -, dhe çdo gjë tjetër jep një 400 invalid_idempotency_key.

Gjithçka tjetër

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

ThirrjaRiprovohetPse
Çdo GETPoNuk ndryshon asgjë.
emails.send, emails.send_batch, templates.send, broadcasts.sendPoNjë çelës idempotence e kthen përsëritjen në riluajtje.
emails.cancel, emails.reschedule, broadcasts.cancel, forms.pause, forms.resume, threads.restorePoNjë vendosje e pastër e një gjendjeje të emërtuar.
threads.update, threads.trashPoNjë vendosje etiketash. Ta zbatosh dy herë është njësoj si ta zbatosh një herë.
threads.snooze, threads.unsnoozePoÇasti i zgjimit ndodhet në trup, nuk nxirret nga koha e mbërritjes.
emails.update, labels.update, webhooks.update, settings.update, roles.update, members.update, domains.update, domains.update_address, domains.update_address_forward, contacts.update, audiences.update, keys.update, forms.update, branding.update, threads.update_note, chats.rename, account.set_email_notification, account.set_push_muted, app_host.set, workspaces.set_activePoNjë vendosje e pastër e fushave të emërtuara.
members.grant_address, members.grant_domain, rules.reorder, threads.reorder_notesPoNjë dhënie qasjeje është një upsert, dhe një renditje deklarohet gjithmonë e plotë.
templates.publish, forms.publish, imports.startPoPublikimi i asaj që është publikuar tashmë, ose nisja e një importi që ka nisur tashmë, e kthen atë të pandryshuar.
templates.preview, templates.render, broadcasts.preview, rules.testPoAto renderojnë, numërojnë ose vlerësojnë dhe nuk shkruajnë asgjë.
domains.verify, app_host.verify, senders.researchPoNjë kontroll i përsëritur nuk ndryshon asgjë përveç kohës kur u bë.
contacts.save, contacts.set_audiences, contacts.remove_photo, contacts.block, contacts.unblock, contacts.delete_many, keys.revoke, files.revoke_link, files.revoke_all_links, app_host.delete, account.remove_photo, branding.remove_image, domains.remove_logo, domains.remove_logo_certificate, domains.remove_address_photo, account.accept_invitation, account.decline_invitation, forms.approve_submission, subscriptions.movePoSecila 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_addressPoNjë 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, account.set_photo, branding.upload_image, domains.set_logo, domains.set_logo_certificate, domains.set_address_photo, imports.upload_chunkPoBajtet 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.uploadJoNjë riprovë lë dy objekte.
drafts.updateJoLexojeni 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, temp_mail.delete_messageJoNjë riprovë pas një përgjigjeje të humbur raporton dështim për punë që pati sukses.
webhooks.rotate_secretJoNjë rrotullim i dytë e bën të pavlefshëm sekretin që ktheu përpjekja e parë.
webhooks.testJoDo të dërgonte një dërgesë të dytë sintetike.
webhooks.replay_deliveryJoDo ta dërgonte ngjarjen te marrësi juaj për herë të dytë.
emails.translate, emails.compose, emails.rewrite, emails.suggest_subjectJoSecila harxhon thirrje modeli, ndaj një riprovim pas një kërkese pa përgjigje e paguan të njëjtën përgjigje dy herë.
security.begin_step_up, security.verify_step_upJoNjë riprovim mund të dërgonte një email të dytë ose të harxhonte një përpjekje të dytë për kodin.
Çdo thirrje tjetër që nuk është GETJoDërgohet një herë, dhe një dështim raportohet në vend që të përsëritet.

Backoff-i

  • E kufizuar nga max_retries: te klienti, me dy përpjekje shtesë si parazgjedhje. max_retries: 0 i çaktivizon riprovat.
  • Vetëm pas një dështimi rrjeti ose pas një 408, 500, 502, 503 ose 504. Një 429 riprovohet vetëm kur mbart Retry-After, dhe kjo API nuk e dërgon, ndaj një kufizim shpejtësie ngre gabim menjëherë. Çdo status tjetër ngre gabim menjëherë.
  • Eksponenciale nga gjysmë sekonde deri në tetë, me luhatje (jitter): çdo pritje është një pikë e rastësishme midis gjysmës së atij tavani dhe tavanit të plotë, që një flotë klientësh të mos sinkronizohet sërish gjatë 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 retry_after_seconds mbi të. Të kthehesh më herët se sa kërkoi ai nuk do të thotë ta respektosh.
  • Skadimi i afatit është një dështim rrjeti si çdo tjetër, ndaj një thirrje që mund të përsëritet pa rrezik provohet sërish pas tij, dhe timeout: zbatohet nga e para për çdo përpjekje.
  • Pritjet janë thirrje sleep brenda thirrjes, ndaj pret edhe fija e ekzekutimit që thërret, dhe thirrja kthehet ose ngre gabim vetëm pasi të ketë përfunduar përpjekja e saj e fundit.