আমরা নিম্নলিখিত বিস্তৃত শ্রেণীতে ত্রুটিগুলিকে শ্রেণীবদ্ধ করেছি:
- প্রমাণীকরণ
- পুনরায় চেষ্টা করা যায়
- বৈধতা
- সিঙ্ক-সম্পর্কিত
যদিও এই বিভাগগুলি সমস্ত সম্ভাব্য ত্রুটিগুলিকে অন্তর্ভুক্ত করে না, এবং কিছু একের বেশি বিভাগে ফিট হতে পারে, তবুও তারা আপনার অ্যাপের ত্রুটি পরিচালনার কাঠামোর জন্য একটি সূচনা পয়েন্ট হিসাবে কাজ করতে পারে৷ একটি নির্দিষ্ট ত্রুটি সম্পর্কে আরো বিস্তারিত জানার জন্য সাধারণ ত্রুটি পড়ুন।
প্রমাণীকরণ ত্রুটি
প্রমাণীকরণ বোঝায় আপনার অ্যাপটিকে ব্যবহারকারীর পক্ষ থেকে Google বিজ্ঞাপন অ্যাক্সেস করার অনুমতি দেওয়া হয়েছে কিনা। প্রমাণীকরণ OAuth2 ফ্লো দ্বারা উত্পন্ন শংসাপত্রের মাধ্যমে পরিচালিত হয়।
আপনার নিয়ন্ত্রণের বাইরের কারণগুলি থেকে একটি প্রমাণীকরণ ত্রুটির সবচেয়ে সাধারণ কারণ হল যে প্রমাণীকৃত ব্যবহারকারী তাদের পক্ষে কাজ করার জন্য আপনার অ্যাপটিকে দেওয়া অনুমতি প্রত্যাহার করেছে৷ উদাহরণস্বরূপ, যদি আপনার অ্যাপ স্বাধীন ক্লায়েন্টদের জন্য আলাদা Google বিজ্ঞাপন অ্যাকাউন্ট পরিচালনা করে এবং সেই ক্লায়েন্টের অ্যাকাউন্ট পরিচালনা করার সময় প্রতিটি ক্লায়েন্ট হিসেবে আলাদাভাবে প্রমাণীকরণ করে, তাহলে একজন ক্লায়েন্ট যেকোনও সময় আপনার অ্যাপের অ্যাক্সেস প্রত্যাহার করতে পারে। আপনার অ্যাক্সেস কখন প্রত্যাহার করা হয়েছিল তার উপর নির্ভর করে, API সরাসরি একটি AuthenticationError.OAUTH_TOKEN_REVOKED
ফেরত দিতে পারে৷ OAUTH_TOKEN_REVOKED ত্রুটি, অথবা ক্লায়েন্ট লাইব্রেরিতে অন্তর্নির্মিত শংসাপত্র বস্তুগুলি একটি টোকেন প্রত্যাহার করা ব্যতিক্রম ছুঁড়ে দিতে পারে৷ উভয় ক্ষেত্রেই, যদি আপনার অ্যাপে আপনার ক্লায়েন্টদের জন্য একটি UI থাকে, তাহলে এটি তাদের পক্ষ থেকে কাজ করার জন্য আপনার অ্যাপের অনুমতি পুনঃস্থাপন করতে OAuth2 ফ্লো পুনরায় চালু করতে বলতে পারে।
পুনরায় চেষ্টাযোগ্য ত্রুটি
কিছু ত্রুটি, যেমন TRANSIENT_ERROR
বা INTERNAL_ERROR
, একটি অস্থায়ী সমস্যা নির্দেশ করতে পারে যা একটি সংক্ষিপ্ত বিরতির পরে অনুরোধটি পুনরায় চেষ্টা করে সমাধান করা যেতে পারে৷
ব্যবহারকারীর সূচনা করা অনুরোধগুলির জন্য, একটি কৌশল হল অবিলম্বে আপনার UI-তে একটি ত্রুটি নির্দেশ করা এবং ব্যবহারকারীকে পুনরায় চেষ্টা করার জন্য একটি বিকল্প দেওয়া। বিকল্পভাবে, আপনার অ্যাপটি প্রথমে স্বয়ংক্রিয়ভাবে অনুরোধটি পুনরায় চেষ্টা করতে পারে, শুধুমাত্র সর্বোচ্চ সংখ্যক পুনঃপ্রচার বা মোট ব্যবহারকারীর অপেক্ষার সময় পৌঁছানোর পরেই UI-তে ত্রুটি প্রকাশ করে।
পিছনের প্রান্তে শুরু করা অনুরোধগুলির জন্য, আপনার অ্যাপটি স্বয়ংক্রিয়ভাবে সর্বোচ্চ সংখ্যক পুনঃপ্রয়াসের জন্য অনুরোধটি পুনরায় চেষ্টা করবে।
যখন আপনি অনুরোধগুলি পুনরায় চেষ্টা করুন, একটি সূচকীয় ব্যাকঅফ নীতি ব্যবহার করুন। উদাহরণস্বরূপ, আপনি যদি প্রথম পুনঃপ্রচেষ্টার 5 সেকেন্ড আগে বিরতি দেন, আপনি দ্বিতীয়টির পরে 10 সেকেন্ড এবং তৃতীয় পুনঃপ্রচেষ্টার পরে 20 সেকেন্ড বিরতি দিতে পারেন। সূচকীয় ব্যাকঅফ নিশ্চিত করতে সাহায্য করে যে আপনি API-কে খুব আক্রমনাত্মকভাবে কল করছেন না।
বৈধতা ত্রুটি
বৈধতা ত্রুটিগুলি নির্দেশ করে যে একটি অপারেশনে একটি ইনপুট গ্রহণযোগ্য ছিল না৷ উদাহরণস্বরূপ, PolicyViolationError
, DateError
, DateRangeError
, StringLengthError
, এবং UrlFieldError
।
বৈধকরণ ত্রুটিগুলি সাধারণত ব্যবহারকারীর দ্বারা শুরু করা অনুরোধগুলিতে ঘটে, যেখানে একজন ব্যবহারকারী অবৈধ ইনপুট প্রবেশ করেছেন৷ এই ক্ষেত্রে, আপনার প্রাপ্ত নির্দিষ্ট API ত্রুটির উপর ভিত্তি করে ব্যবহারকারীকে একটি উপযুক্ত ত্রুটি বার্তা প্রদান করা উচিত। আপনি একটি API কল করার আগে সাধারণ ভুলগুলির জন্য ব্যবহারকারীর ইনপুট যাচাই করতে পারেন, আপনার অ্যাপটিকে আরও প্রতিক্রিয়াশীল করে এবং আপনার API ব্যবহারকে আরও দক্ষ করে তোলে৷ পিছনের প্রান্ত থেকে অনুরোধের জন্য, আপনার অ্যাপটি একটি মানব অপারেটরের পর্যালোচনা করার জন্য একটি সারিতে ব্যর্থ অপারেশন যুক্ত করতে পারে।
সিঙ্ক-সম্পর্কিত ত্রুটি
অনেক Google বিজ্ঞাপন অ্যাপ তাদের Google বিজ্ঞাপন বস্তু সংরক্ষণ করার জন্য একটি স্থানীয় ডাটাবেস বজায় রাখে। এই পদ্ধতির একটি চ্যালেঞ্জ হল যে স্থানীয় ডেটাবেস Google বিজ্ঞাপনের প্রকৃত বস্তুর সাথে সিঙ্কের বাইরে চলে যেতে পারে। উদাহরণস্বরূপ, একজন ব্যবহারকারী সরাসরি Google বিজ্ঞাপনে একটি বিজ্ঞাপন গোষ্ঠী মুছে ফেলতে পারে, কিন্তু অ্যাপ এবং স্থানীয় ডাটাবেস পরিবর্তন সম্পর্কে অবগত নয় এবং বিজ্ঞাপন গোষ্ঠীর অস্তিত্বের মতো API কল ইস্যু করা চালিয়ে যেতে পারে। এই সিঙ্ক সমস্যাগুলি বিভিন্ন ত্রুটি যেমন DUPLICATE_CAMPAIGN_NAME
, DUPLICATE_ADGROUP_NAME
, AD_NOT_UNDER_ADGROUP
, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD
, এবং আরও অনেকগুলি হিসাবে প্রকাশ করতে পারে৷
ব্যবহারকারীর সূচনা করা অনুরোধগুলির জন্য, একটি কৌশল হল সম্ভাব্য সিঙ্ক সমস্যা সম্পর্কে ব্যবহারকারীকে সতর্ক করা, অবিলম্বে একটি কাজ চালু করা যা Google বিজ্ঞাপন অবজেক্টের প্রাসঙ্গিক ক্লাস পুনরুদ্ধার করে এবং স্থানীয় ডাটাবেস আপডেট করে, তারপর ব্যবহারকারীকে UI রিফ্রেশ করার জন্য অনুরোধ করে।
ব্যাক-এন্ড অনুরোধের জন্য, কিছু ত্রুটি আপনার অ্যাপকে স্বয়ংক্রিয়ভাবে এবং ক্রমবর্ধমানভাবে আপনার স্থানীয় ডাটাবেস সংশোধন করার জন্য যথেষ্ট তথ্য প্রদান করে। উদাহরণস্বরূপ, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD
আপনার স্থানীয় ডাটাবেসে সেই বিজ্ঞাপনটিকে সরানো হিসাবে চিহ্নিত করার জন্য আপনার অ্যাপের কারণ হওয়া উচিত৷ যে ত্রুটিগুলি আপনি এইভাবে পরিচালনা করতে পারবেন না তার কারণে আপনার অ্যাপটি আরও সম্পূর্ণ সিঙ্ক কাজ চালু করতে পারে বা একটি মানব অপারেটরের পর্যালোচনার জন্য একটি সারিতে যুক্ত হতে পারে৷