गड़बड़ी के प्रकार

हमने गड़बड़ियों को इन कैटगरी में बांटा है:

• पुष्टि करना
• ऐसी गड़बड़ियां जिन्हें ठीक करने के लिए फिर से कोशिश की जा सकती है
• पुष्टि
• सिंक करने से जुड़ी

इन कैटगरी में सभी संभावित गड़बड़ियां शामिल नहीं हैं. साथ ही, कुछ गड़बड़ियां एक से ज़्यादा कैटगरी में फ़िट हो सकती हैं. हालांकि, ये कैटगरी, आपके ऐप्लिकेशन में गड़बड़ी ठीक करने की प्रोसेस को व्यवस्थित करने के लिए शुरुआती बिंदु के तौर पर काम कर सकती हैं. किसी गड़बड़ी के बारे में ज़्यादा जानकारी पाने के लिए, यहां दिए गए लेख पढ़ें:

• आम तौर पर होने वाली गड़बड़ियां से, किसी गड़बड़ी के बारे में ज़्यादा जानकारी मिलती है.
• google.rpc.Status में, एपीआई के इस्तेमाल किए गए लॉजिकल एरर मॉडल के बारे में जानकारी दी गई है.
• कैननिकल गड़बड़ी के कोड में, Google Ads API के संदर्भ में gRPC और एचटीटीपी के तय किए गए कैननिकल गड़बड़ी के कोड की सूची और उनके बारे में जानकारी दी गई है.

पुष्टि करने से जुड़ी गड़बड़ियां

पुष्टि करने का मतलब है कि किसी व्यक्ति ने आपके ऐप्लिकेशन को उसकी ओर से Google Ads को ऐक्सेस करने की अनुमति दी है या नहीं. पुष्टि की प्रोसेस को, OAuth2 फ़्लो से जनरेट किए गए क्रेडेंशियल के ज़रिए मैनेज किया जाता है.

पुष्टि करने में गड़बड़ी होने की सबसे आम वजह यह है कि पुष्टि किए गए उपयोगकर्ता ने, आपके ऐप्लिकेशन को उसकी ओर से कार्रवाई करने की अनुमति वापस ले ली है. इस गड़बड़ी को ठीक करने के लिए, आपको उपयोगकर्ता से अनुमति दोबारा लेनी होगी. उदाहरण के लिए, अगर आपका ऐप्लिकेशन अलग-अलग क्लाइंट के Google Ads खातों को मैनेज करता है और हर क्लाइंट के खाते को मैनेज करते समय, क्लाइंट के तौर पर अलग से पुष्टि करता है, तो क्लाइंट आपके ऐप्लिकेशन के ऐक्सेस को किसी भी समय रद्द कर सकता है. ऐक्सेस रद्द होने के समय के आधार पर, एपीआई सीधे तौर पर AuthenticationError.OAUTH_TOKEN_REVOKED गड़बड़ी दिखा सकता है. इसके अलावा, क्लाइंट लाइब्रेरी में मौजूद क्रेडेंशियल ऑब्जेक्ट, टोकन रद्द होने की वजह से अपवाद दिखा सकते हैं. इन दोनों ही मामलों में, अगर आपके ऐप्लिकेशन में क्लाइंट के लिए यूज़र इंटरफ़ेस (यूआई) है, तो वह क्लाइंट से OAuth 2.0 फ़्लो को फिर से लॉन्च करने के लिए कह सकता है. इससे, आपके ऐप्लिकेशन को क्लाइंट की ओर से कार्रवाई करने की अनुमति फिर से मिल जाएगी.

इसी तरह, अगर आपके Google Cloud प्रोजेक्ट में सिर्फ़ टेस्ट ऐक्सेस लेवल है और वह प्रोडक्शन (टेस्ट के अलावा) खाते के लिए अनुरोध करता है, तो एपीआई AuthorizationError दिखाता है. इसकी इनम वैल्यू, एपीआई के वर्शन पर निर्भर करती है:

• v25 से शुरू होने वाले बदलाव: खरीदारों के लिए सामान लौटाने की सुविधा AuthorizationError.CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION.
• v24 और इससे पहले के वर्शन: यह फ़ंक्शन AuthorizationError.ACTION_NOT_PERMITTED दिखाता है.

ऐसी गड़बड़ियां जिन्हें ठीक करने के लिए फिर से कोशिश की जा सकती है

कुछ गड़बड़ियां, जैसे कि TRANSIENT_ERROR या INTERNAL_ERROR, कुछ समय के लिए होने वाली समस्या का संकेत दे सकती हैं. इस समस्या को ठीक करने के लिए, कुछ समय बाद अनुरोध को फिर से आज़माएं.

उपयोगकर्ता के अनुरोधों के लिए, एक रणनीति यह है कि अपने यूज़र इंटरफ़ेस (यूआई) में तुरंत गड़बड़ी का मैसेज दिखाएं. साथ ही, उपयोगकर्ता को फिर से कोशिश करने का विकल्प दें. इसके अलावा, आपका ऐप्लिकेशन पहले अनुरोध को अपने-आप फिर से आज़मा सकता है. हालांकि, गड़बड़ी को यूज़र इंटरफ़ेस (यूआई) में सिर्फ़ तब दिखाया जाएगा, जब अनुरोध को फिर से आज़माने की ज़्यादा से ज़्यादा संख्या पूरी हो जाएगी या उपयोगकर्ता के इंतज़ार का कुल समय पूरा हो जाएगा.

बैकएंड पर शुरू किए गए अनुरोधों के लिए, आपके ऐप्लिकेशन को अनुरोध को अपने-आप फिर से भेजने की कोशिश करनी चाहिए. हालांकि, ऐसा ज़्यादा से ज़्यादा बार किया जाना चाहिए.

अनुरोधों को फिर से भेजने की कोशिश करते समय, एक्स्पोनेंशियल बैकऑफ़ नीति का इस्तेमाल करें. साथ ही, उसमें रैंडमाइज़्ड जिटर का इस्तेमाल करें. उदाहरण के लिए, अगर पहली बार फिर से कोशिश करने से पहले पांच सेकंड के लिए रोका जाता है, तो दूसरी बार फिर से कोशिश करने से पहले 10 सेकंड और तीसरी बार फिर से कोशिश करने से पहले 20 सेकंड के लिए रोका जा सकता है. साथ ही, हर इंटरवल में कुछ समय के लिए रैंडम देरी जोड़कर, एक साथ कई बार फिर से कोशिश करने से रोका जा सकता है. एक्सपोनेंशियल बैकऑफ़ की मदद से, यह पक्का किया जाता है कि एपीआई को बहुत ज़्यादा कॉल न किया जाए. अगर बार-बार कोशिश करने के बाद भी गड़बड़ी बनी रहती है, तो समस्या हल करने के लिए, जवाब से request-id को लॉग करें.

पुष्टि से जुड़ी गड़बड़ियां

पुष्टि करने से जुड़ी गड़बड़ियों से पता चलता है कि किसी कार्रवाई के लिए दिया गया इनपुट स्वीकार नहीं किया गया. उदाहरण के लिए, PolicyViolationError, DateError, DateRangeError, StringLengthError, और UrlFieldError.

पुष्टि करने से जुड़ी गड़बड़ियां, आम तौर पर उपयोगकर्ता के शुरू किए गए अनुरोधों में होती हैं. ऐसा तब होता है, जब उपयोगकर्ता ने अमान्य इनपुट डाला हो. ऐसे मामलों में, आपको उपयोगकर्ता को गड़बड़ी का सही मैसेज देना चाहिए. यह मैसेज, आपको मिली एपीआई से जुड़ी गड़बड़ी पर आधारित होना चाहिए. एपीआई कॉल करने से पहले, सामान्य गलतियों के लिए उपयोगकर्ता के इनपुट की पुष्टि भी की जा सकती है. इससे आपका ऐप्लिकेशन ज़्यादा तेज़ी से काम करता है और एपीआई का इस्तेमाल ज़्यादा असरदार तरीके से होता है. बैकएंड से किए गए अनुरोधों के लिए, आपका ऐप्लिकेशन फ़ेल हुए ऑपरेशन को एक ऐसी कतार में जोड़ सकता है जिसे कोई व्यक्ति समीक्षा कर सके.

सिंक करने से जुड़ी गड़बड़ियां

Google Ads के कई ऐप्लिकेशन, Google Ads ऑब्जेक्ट को सेव करने के लिए लोकल डेटाबेस का इस्तेमाल करते हैं. इस तरीके में एक चुनौती यह है कि लोकल डेटाबेस, Google Ads में मौजूद असल ऑब्जेक्ट के साथ सिंक नहीं हो पाता. उदाहरण के लिए, ऐसा हो सकता है कि कोई उपयोगकर्ता Google Ads में सीधे तौर पर किसी विज्ञापन ग्रुप को मिटा दे. हालांकि, ऐप्लिकेशन और लोकल डेटाबेस को इस बदलाव के बारे में पता नहीं चलता है. इसलिए, वे एपीआई कॉल जारी रखते हैं, जैसे कि विज्ञापन ग्रुप मौजूद हो. सिंक करने से जुड़ी इन समस्याओं की वजह से, कई तरह की गड़बड़ियां हो सकती हैं. जैसे, DUPLICATE_CAMPAIGN_NAME, DUPLICATE_ADGROUP_NAME, AD_NOT_UNDER_ADGROUP, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD, और अन्य गड़बड़ियां.

उपयोगकर्ता के अनुरोधों के लिए, एक रणनीति यह है कि उपयोगकर्ता को सिंक करने से जुड़ी संभावित समस्या के बारे में सूचना दी जाए. इसके बाद, तुरंत एक ऐसा टास्क शुरू किया जाए जो Google Ads ऑब्जेक्ट की ज़रूरी क्लास को वापस लाता है और लोकल डेटाबेस को अपडेट करता है. इसके बाद, उपयोगकर्ता को यूज़र इंटरफ़ेस (यूआई) को रीफ़्रेश करने के लिए कहा जाए.

बैकएंड के अनुरोधों के लिए, कुछ गड़बड़ियों से आपके ऐप्लिकेशन को इतनी जानकारी मिल जाती है कि वह आपके स्थानीय डेटाबेस को अपने-आप और धीरे-धीरे ठीक कर सकता है. उदाहरण के लिए, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD से आपके ऐप्लिकेशन को, स्थानीय डेटाबेस में उस विज्ञापन को 'हटाया गया' के तौर पर मार्क करना चाहिए. इस तरीके से ठीक न की जा सकने वाली गड़बड़ियों की वजह से, आपका ऐप्लिकेशन ज़्यादा बेहतर तरीके से सिंक हो सकता है. इसके अलावा, इसे मैन्युअल तरीके से समीक्षा करने के लिए, ऑपरेटर की कतार में जोड़ा जा सकता है.