पुनः प्रयास और idempotency
क्या retry होता है, क्या जानबूझकर नहीं, और क्यों retry किया गया send दोहरा नहीं सकता।
भेजना
क्लाइंट हर send (emails.send, emails.send_batch, templates.send और broadcasts.send) पर एक Idempotency-Key जोड़ता है, जो प्रति **कॉल** एक बार बनती है और उस कॉल के retry उसी को दोबारा इस्तेमाल करते हैं। API कुछ भी भेजने से पहले उस key पर दावा कर लेता है, इसलिए retry दूसरा संदेश भेजने के बजाय मूल संदेश को दोहराता है, जबकि जानबूझकर किए गए दो send() कॉल फिर भी दो बार भेजते हैं। ये अलग इरादे हैं और अलग ही रहते हैं।
अपनी idempotency_key देकर उस गारंटी को प्रक्रियाओं के पार खींचें, ताकि जो job क्रैश होकर दोबारा चली, वह अपने send दोहराने के बजाय उन्हें replay करे।
invoice_id = 'inv_4192' client.emails.send( {'from': sender, 'to': recipient, 'subject': subject, 'text': text}, idempotency_key=f'invoice:{invoice_id}',)इसे उसी चीज़ से निकालें जिसने send को ज़रूरी बनाया। घड़ी से कभी नहीं। अलग body के साथ वही key दोबारा इस्तेमाल करना चुपचाप replay होने के बजाय idempotency_key_reuse के साथ अस्वीकार होता है।
बाकी सब
हर read retry होता है। कोई write केवल तभी retry होता है जब दूसरा हूबहू वही request पहले से कुछ अलग मायने रख ही न सके, और send इस कसौटी पर खरा उतरता है क्योंकि उसकी idempotency key दोहराव को replay में बदल देती है।
| कॉल | पुनः प्रयास | क्यों |
|---|---|---|
| हर read | हाँ | कुछ नहीं बदलता। |
| emails.send, emails.send_batch, templates.send और broadcasts.send | हाँ | idempotency key दोहराव को replay बना देती है। |
| emails.cancel, emails.reschedule, broadcasts.cancel, forms.publish, forms.pause, forms.resume, forms.approve_submission, account.accept_invitation और account.decline_invitation | हाँ | किसी नामित स्थिति का शुद्ध सेट। |
| threads.update, threads.trash और threads.restore | हाँ | लेबल का सेट। उसे दो बार लगाना एक बार लगाना ही है। |
| threads.snooze, threads.unsnooze | हाँ | जागने का क्षण body में होता है, आगमन के समय से नहीं निकाला जाता। |
| 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 और workspaces.set_active | हाँ | नामित फ़ील्ड का शुद्ध सेट। |
| members.grant_address, members.grant_domain, rules.reorder और threads.reorder_notes | हाँ | grant एक upsert है, और क्रम पूरा का पूरा बताया जाता है। |
| templates.publish, imports.start | हाँ | पहले से प्रकाशित head को प्रकाशित करने पर, या पहले से शुरू हो चुके import को शुरू करने पर, वह अपरिवर्तित लौटता है। |
| templates.preview, templates.render, broadcasts.preview और rules.test | हाँ | ये render करते हैं, गिनते हैं या मूल्यांकन करते हैं, लिखते कुछ नहीं। |
| domains.verify, app_host.verify | हाँ | दोहराई गई जाँच, जाँच के समय के अलावा कुछ नहीं बदलती। |
| 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 और subscriptions.move | हाँ | हर एक अंतिम परिणाम बताता है, इसलिए दूसरा कॉल वही छोड़ता है जो पहले ने छोड़ा था। |
| audiences.add_contact, audiences.add_contacts, audiences.remove_contacts, audiences.import_contacts, suppressions.add, domains.create_address और senders.research | हाँ | दोहराव पहले कॉल का काम पहले से हुआ पाता है और उसे दो बार करने के बजाय उसकी सूचना देता है। |
| contacts.set_photo, imports.upload_chunk, account.set_photo, branding.upload_image, domains.set_logo, domains.set_logo_certificate और domains.set_address_photo | हाँ | दोबारा भेजे गए बाइट्स वह बदल देते हैं जो पहली कोशिश ने संग्रहीत किया था। |
| drafts.create, labels.create, webhooks.create, templates.create, rules.create, roles.create, temp_mail.create, files.upload, templates.design और forms.design | नहीं | retry दो object छोड़ जाता है। |
| drafts.update | नहीं | जो id आपने भेजी थी उसे दोबारा इस्तेमाल करने के बजाय हर write के परिणाम से id पढ़ें। |
| drafts.delete, labels.delete, webhooks.delete, templates.delete, rules.delete, roles.delete, members.remove, members.revoke_address, temp_mail.delete और temp_mail.delete_message | नहीं | रिस्पॉन्स खो जाने के बाद किया गया retry उस काम को विफल बताता है जो सफल हो चुका था। |
| webhooks.rotate_secret | नहीं | दूसरा rotation उस secret को रद्द कर देता है जो पहली कोशिश ने लौटाया था। |
| webhooks.test | नहीं | यह दूसरी बनावटी delivery भेज देता। |
| webhooks.replay_delivery | नहीं | यह event को आपके receiver को दूसरी बार भेज देता। |
| emails.translate | नहीं | यह मॉडल कॉल खर्च करता है, इसलिए बिना उत्तर वाले request के बाद किया गया retry वही उत्तर दो बार खरीदता है। |
| emails.compose, emails.rewrite और emails.suggest_subject | नहीं | हर प्रयास एक और AI कार्रवाई ख़र्च करता है और एक अलग उत्तर के साथ लौटता है। |
| हर दूसरी कॉल | नहीं | एक ही बार भेजा जाता है, और विफलता दोहराई नहीं बल्कि बताई जाती है। |
forms.update expectedUpdatedAt के साथ भी retry होता है, इसलिए रिस्पॉन्स खो जाने के बाद किया गया retry 409 version_conflict के साथ लौट सकता है, क्योंकि पहली कोशिश सफल हो चुकी थी। दोबारा कोशिश करने से पहले फ़ॉर्म पढ़ लें।
client.raw.request GET को retry करता है और बाकी सब कुछ एक ही बार भेजता है, जब तक आप repeatable=True पास न करें।
बैकऑफ़
- क्लाइंट पर
max_retriesसे सीमित, जिसका डिफ़ॉल्ट दो अतिरिक्त कोशिशें हैं। - केवल नेटवर्क विफलता या
408,500,502,503या504के बाद।429तभी retry होता है जब वहRetry-Afterलिए आए, और यह API उसे नहीं भेजता, इसलिए rate limit सीधे raise होता है। कोई भी दूसरा status तुरंत raise होता है। - आधे सेकंड से आठ सेकंड तक घातीय, jitter के साथ, ताकि रिकवरी पर पूरा बेड़ा फिर से एक साथ न आ जाए।
Retry-Afterकी गति से, उसके दोनों रूपों में: delay-seconds और HTTP-date। जब सर्वर प्रतीक्षा बताता है, तो क्लाइंट backoff करने के बजाय ठीक उतनी ही देर रुकता है।- एक मिनट से ज़्यादा माँगने वाले सर्वर को क्लाइंट से सोने को नहीं, रुक जाने को कहना माना जाता है, इसलिए error उस पर
retry_after_secondsके साथ उठाई जाती है। उसके माँगे से जल्दी लौटना उसका पालन नहीं है। timeoutहर प्रयास की सीमा तय करता है, इसलिए जो कॉल अपने दोनों retry इस्तेमाल करती है, उसमें तीन timeout और उनके बीच की प्रतीक्षाएँ लग सकती हैं।AsyncOpenEmailकॉल का रद्दीकरण कभी retry नहीं होता। रद्दीकरण तुरंत propagate होता है, चाहे अनुरोध से हो या अगली कोशिश से पहले की प्रतीक्षा से।