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

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

• पुष्टि करना
• फिर से कोशिश की जा सकती है
• पुष्टि
• सिंक करने से जुड़ी

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

• आम गड़बड़ियां सेक्शन में, किसी खास गड़बड़ी के बारे में ज़्यादा जानकारी मिलती है.
• एपीआई के इस्तेमाल किए गए लॉजिकल गड़बड़ी मॉडल के बारे में जानकारी के लिए, google.rpc.Status.

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

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

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

दोबारा कोशिश की जा सकने वाली गड़बड़ियां

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

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

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

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

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

पुष्टि करने से जुड़ी गड़बड़ियां बताती हैं कि किसी कार्रवाई के लिए दिया गया इनपुट स्वीकार नहीं किया जा सका. उदाहरण के लिए, 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 के ज़रिए, आपका ऐप्लिकेशन उस विज्ञापन को अपने स्थानीय डेटाबेस में 'हटाया गया' के तौर पर मार्क कर देगा. अगर गड़बड़ियों को इस तरीके से ठीक नहीं किया जा सकता, तो हो सकता है कि आपका ऐप्लिकेशन सिंक करने का ज़्यादा बेहतर जॉब लॉन्च करे. इसके अलावा, गड़बड़ियों को किसी ऑपरेटर की समीक्षा के लिए सूची में जोड़ा जा सकता है.