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

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

• पुष्टि करना
• फिर से कोशिश करने के दौरान होने वाली गड़बड़ियां
• पुष्टि
• सिंक करने के दौरान होने वाली गड़बड़ियां

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

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

पुष्टि करने के दौरान होने वाली गड़बड़ियां

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