ত্রুটির ধরন

আমরা ত্রুটিগুলিকে নিম্নলিখিত বিস্তৃত বিভাগে শ্রেণীবদ্ধ করেছি:

• প্রমাণীকরণ
• পুনরায় চেষ্টা করা যাবে
• বৈধতা
• সিঙ্ক-সম্পর্কিত

যদিও এই বিভাগগুলিতে সমস্ত সম্ভাব্য ত্রুটি অন্তর্ভুক্ত নয়, এবং কিছু একাধিক বিভাগে ফিট হতে পারে, তবুও এগুলি আপনার অ্যাপের ত্রুটি পরিচালনার কাঠামো তৈরির জন্য একটি সূচনা বিন্দু হিসাবে কাজ করতে পারে। নির্দিষ্ট ত্রুটি সম্পর্কে আরও বিশদের জন্য নিম্নলিখিত সংস্থানগুলি দেখুন:

• সাধারণ ত্রুটি একটি নির্দিষ্ট ত্রুটি সম্পর্কে আরও বিশদ প্রদান করে।
• API দ্বারা ব্যবহৃত লজিক্যাল ত্রুটি মডেল সম্পর্কে বিস্তারিত জানার জন্য google.rpc.Status দেখুন ।
• Google Ads API-এর প্রেক্ষাপটে gRPC এবং HTTP দ্বারা সংজ্ঞায়িত ক্যানোনিকাল ত্রুটি কোডগুলির তালিকা এবং ব্যাখ্যার জন্য ক্যানোনিকাল ত্রুটি কোড ।

প্রমাণীকরণ ত্রুটি

প্রমাণীকরণ বলতে বোঝায় যে আপনার অ্যাপটিকে কোনও ব্যবহারকারী তাদের পক্ষ থেকে Google বিজ্ঞাপন অ্যাক্সেস করার অনুমতি দিয়েছেন কিনা। OAuth2 প্রবাহ দ্বারা তৈরি শংসাপত্রের মাধ্যমে প্রমাণীকরণ পরিচালিত হয়।

আপনার নিয়ন্ত্রণের বাইরের কারণগুলির কারণে প্রমাণীকরণ ত্রুটির সবচেয়ে সাধারণ কারণ হল প্রমাণীকরণকৃত ব্যবহারকারী আপনার অ্যাপকে তাদের পক্ষ থেকে কাজ করার অনুমতি প্রত্যাহার করেছেন। উদাহরণস্বরূপ, যদি আপনার অ্যাপটি স্বাধীন ক্লায়েন্টদের জন্য পৃথক Google বিজ্ঞাপন অ্যাকাউন্ট পরিচালনা করে এবং সেই ক্লায়েন্টের অ্যাকাউন্ট পরিচালনা করার সময় প্রতিটি ক্লায়েন্ট হিসাবে পৃথকভাবে প্রমাণীকরণ করে, তাহলে একজন ক্লায়েন্ট যেকোনো সময় আপনার অ্যাপের অ্যাক্সেস প্রত্যাহার করতে পারে। আপনার অ্যাক্সেস কখন প্রত্যাহার করা হয়েছে তার উপর নির্ভর করে, API সরাসরি একটি AuthenticationError.OAUTH_TOKEN_REVOKED ত্রুটি ফেরত দিতে পারে, অথবা ক্লায়েন্ট লাইব্রেরিতে অন্তর্নির্মিত শংসাপত্র বস্তু একটি টোকেন প্রত্যাহার ব্যতিক্রম ছুঁড়ে দিতে পারে। উভয় ক্ষেত্রেই, যদি আপনার অ্যাপে আপনার ক্লায়েন্টদের জন্য একটি UI থাকে, তাহলে এটি তাদের পক্ষে কাজ করার জন্য আপনার অ্যাপের অনুমতি পুনঃস্থাপন করার জন্য OAuth2 প্রবাহ পুনরায় চালু করতে বলতে পারে।

পুনরায় চেষ্টা করার যোগ্য ত্রুটি

কিছু ত্রুটি, যেমন TRANSIENT_ERROR অথবা INTERNAL_ERROR , একটি অস্থায়ী সমস্যা নির্দেশ করতে পারে যা কিছুক্ষণ বিরতির পরে অনুরোধটি পুনরায় চেষ্টা করে সমাধান করা যেতে পারে।

ব্যবহারকারীর দ্বারা শুরু করা অনুরোধের ক্ষেত্রে, একটি কৌশল হল আপনার UI-তে একটি ত্রুটি অবিলম্বে নির্দেশ করা এবং ব্যবহারকারীকে পুনরায় চেষ্টা করার জন্য একটি বিকল্প দেওয়া। বিকল্পভাবে, আপনার অ্যাপটি প্রথমে স্বয়ংক্রিয়ভাবে অনুরোধটি পুনরায় চেষ্টা করতে পারে, কেবলমাত্র সর্বোচ্চ সংখ্যক পুনরায় চেষ্টা বা ব্যবহারকারীর মোট অপেক্ষার সময় পৌঁছানোর পরে UI-তে ত্রুটিটি প্রকাশ করে।

ব্যাক-এন্ডে শুরু করা অনুরোধগুলির জন্য, আপনার অ্যাপটি স্বয়ংক্রিয়ভাবে সর্বাধিক সংখ্যক পুনরায় চেষ্টা করার জন্য অনুরোধটি পুনরায় চেষ্টা করবে।

যখন আপনি অনুরোধগুলি পুনরায় চেষ্টা করেন, তখন একটি সূচকীয় ব্যাকঅফ নীতি ব্যবহার করুন। উদাহরণস্বরূপ, যদি আপনি প্রথম পুনঃচেষ্টার 5 সেকেন্ড আগে প্রথম বিরতি দেন, তাহলে আপনি দ্বিতীয়টির পরে 10 সেকেন্ড এবং তৃতীয় পুনঃচেষ্টার পরে 20 সেকেন্ড বিরতি দিতে পারেন। সূচকীয় ব্যাকঅফ নিশ্চিত করতে সাহায্য করে যে আপনি API-কে খুব আক্রমণাত্মকভাবে কল করছেন না।

যাচাইকরণ ত্রুটি

যাচাইকরণ ত্রুটিগুলি নির্দেশ করে যে কোনও অপারেশনের ইনপুট গ্রহণযোগ্য ছিল না। উদাহরণস্বরূপ, PolicyViolationError , DateError , DateRangeError , StringLengthError , এবং UrlFieldError ।

ব্যবহারকারীর দ্বারা শুরু করা অনুরোধগুলিতে যাচাইকরণ ত্রুটিগুলি সবচেয়ে বেশি ঘটে, যেখানে কোনও ব্যবহারকারী অবৈধ ইনপুট প্রবেশ করিয়েছেন। এই ক্ষেত্রে, আপনার প্রাপ্ত নির্দিষ্ট API ত্রুটির উপর ভিত্তি করে ব্যবহারকারীকে একটি উপযুক্ত ত্রুটি বার্তা প্রদান করা উচিত। API কল করার আগে আপনি সাধারণ ভুলগুলির জন্য ব্যবহারকারীর ইনপুট যাচাই করতে পারেন, যা আপনার অ্যাপটিকে আরও প্রতিক্রিয়াশীল এবং আপনার API ব্যবহারকে আরও দক্ষ করে তুলবে। ব্যাক এন্ড থেকে অনুরোধের জন্য, আপনার অ্যাপটি ব্যর্থ অপারেশনটিকে একটি মানব অপারেটরের পর্যালোচনার জন্য একটি সারিতে যুক্ত করতে পারে।

সিঙ্ক-সম্পর্কিত ত্রুটি

অনেক Google Ads অ্যাপ তাদের Google Ads অবজেক্ট সংরক্ষণের জন্য একটি স্থানীয় ডাটাবেস বজায় রাখে। এই পদ্ধতির একটি চ্যালেঞ্জ হল স্থানীয় ডাটাবেস Google Ads-এর আসল অবজেক্টের সাথে সিঙ্ক্রোনাইজ হতে পারে। উদাহরণস্বরূপ, একজন ব্যবহারকারী সরাসরি Google Ads-এ একটি বিজ্ঞাপন গ্রুপ মুছে ফেলতে পারেন, কিন্তু অ্যাপ এবং স্থানীয় ডাটাবেস পরিবর্তন সম্পর্কে অবগত থাকে না এবং API কল ইস্যু করতে থাকে যেন বিজ্ঞাপন গ্রুপটি বিদ্যমান। এই সিঙ্ক সমস্যাগুলি বিভিন্ন ত্রুটির মতো প্রকাশ পেতে পারে যেমন DUPLICATE_CAMPAIGN_NAME , DUPLICATE_ADGROUP_NAME , AD_NOT_UNDER_ADGROUP , CANNOT_OPERATE_ON_REMOVED_ADGROUPAD , এবং আরও অনেক কিছু।

ব্যবহারকারীর দ্বারা শুরু করা অনুরোধের ক্ষেত্রে, একটি কৌশল হল ব্যবহারকারীকে সম্ভাব্য সিঙ্ক সমস্যার বিষয়ে সতর্ক করা, অবিলম্বে এমন একটি কাজ শুরু করা যা Google বিজ্ঞাপনের বস্তুর প্রাসঙ্গিক শ্রেণী পুনরুদ্ধার করে এবং স্থানীয় ডাটাবেস আপডেট করে, তারপর ব্যবহারকারীকে UI রিফ্রেশ করতে অনুরোধ করে।

ব্যাক-এন্ড অনুরোধের ক্ষেত্রে, কিছু ত্রুটি আপনার অ্যাপকে পর্যাপ্ত তথ্য প্রদান করে যা আপনার স্থানীয় ডাটাবেস স্বয়ংক্রিয়ভাবে এবং ক্রমবর্ধমানভাবে সংশোধন করতে পারে। উদাহরণস্বরূপ, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD ফলে আপনার অ্যাপটি আপনার স্থানীয় ডাটাবেসে সেই বিজ্ঞাপনটিকে সরানো হয়েছে বলে চিহ্নিত করবে। আপনি যে ত্রুটিগুলি এইভাবে পরিচালনা করতে পারবেন না সেগুলির ফলে আপনার অ্যাপটি আরও সম্পূর্ণ সিঙ্ক কাজ শুরু করতে পারে অথবা একজন মানব অপারেটরের পর্যালোচনার জন্য একটি সারিতে যুক্ত হতে পারে।