सही पुनर्प्राप्ति चुनें
एक ही त्रुटि कोड दो भिन्न स्थितियों का वर्णन करता है। कोई कार्रवाई करने से पहलेretryable जाँचें; केवल HTTP स्टेटस से यह पता नहीं चलता कि पुनः प्रयास करना है या नहीं।
भिन्न इनपुट
अनुरोध अभी प्रोसेस हो रहा है
इस उदाहरण में HTTP प्रतिक्रिया हेडरRetry-After: 1 भी शामिल है।
पुनः प्रयास की पहचान स्थिर रखें
जिन ऑपरेशनों के लिए idempotency प्रलेखित है, उनमें key का दायरा संगठन, सर्विस अकाउंट, HTTP मेथड, रिसोर्स पाथ और निर्धारित API वर्ज़न तक सीमित होता है। इनमें से किसी को भी बदलने से एक भिन्न पुनः प्रयास पहचान बन जाती है; इससे मूल ऑपरेशन की पुनर्प्राप्ति नहीं होती। उसी सर्विस अकाउंट के अंतर्गत क्रेडेंशियल बदलने से यह पहचान नहीं बदलती, हालाँकि नए क्रेडेंशियल के पास अनुमति होना अब भी आवश्यक है। टाइमआउट से उबरते समय मूल key, बॉडी, पाथ और वर्ज़न को यथावत रखें। केवल संघर्ष से बचने के लिए नई key जनरेट न करें: मूल राइट पहले ही सफल हो चुका हो सकता है। यदि रिसोर्स की ID ज्ञात है, तो रिसोर्स को प्राप्त करें और ऑपरेशन की प्रलेखित पुनर्प्राप्ति प्रक्रिया का उपयोग करें। जहाँ ऑपरेशन प्रतिक्रिया रीप्ले को प्रलेखित करता है, वहाँ पूरा हो चुका रीप्लेIdempotent-Replayed: true के साथ आता है।
Idempotency-Key भेजने से कोई ऑपरेशन idempotent नहीं बन जाता, जब तक कि उसके संदर्भ में उस हेडर का स्पष्ट रूप से समर्थन न किया गया हो। पुनः प्रयास सुरक्षा ऑपरेशन की रिटेंशन नीति तक सीमित है; यह डुप्लिकेट के विरुद्ध स्थायी गारंटी नहीं है।
यदि प्रोसेसिंग अनसुलझी रहती है, तो request_id, UTC टाइमस्टैम्प, मेथड, पाथ और API वर्ज़न के साथ Living Security Support से संपर्क करें। API key, क्लाइंट सीक्रेट या एक्सेस टोकन कभी शामिल न करें।