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

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

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

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

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

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

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