ত্রুটির ধরন

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

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

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

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

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

অথেনটিকেশন বলতে বোঝায়, কোনো ব্যবহারকারী আপনার অ্যাপকে তার পক্ষ থেকে গুগল অ্যাডস অ্যাক্সেস করার অনুমতি দিয়েছে কি না। OAuth2 ফ্লো দ্বারা তৈরি ক্রেডেনশিয়ালের মাধ্যমে অথেনটিকেশন পরিচালিত হয়।

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

এই প্রসঙ্গে, যদি আপনার গুগল ক্লাউড প্রজেক্টে শুধুমাত্র টেস্ট অ্যাক্সেস লেভেল থাকে এবং আপনি একটি প্রোডাকশন (নন-টেস্ট) অ্যাকাউন্টের বিরুদ্ধে অনুরোধ করার চেষ্টা করেন, তাহলে API একটি AuthorizationError রিটার্ন করে, যার enum ভ্যালুটি API ভার্সনের উপর নির্ভর করে:

• v25 থেকে শুরু করে : AuthorizationError.CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION রিটার্ন করে।
• v24 এবং পূর্ববর্তী সংস্করণ: AuthorizationError.ACTION_NOT_PERMITTED রিটার্ন করে।

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

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

ব্যবহারকারীর পাঠানো অনুরোধের ক্ষেত্রে একটি কৌশল হলো, আপনার ইউজার ইন্টারফেসে (UI) তাৎক্ষণিকভাবে একটি ত্রুটি নির্দেশ করা এবং ব্যবহারকারীকে পুনরায় চেষ্টা করার সুযোগ দেওয়া। বিকল্পভাবে, আপনার অ্যাপটি প্রথমে স্বয়ংক্রিয়ভাবে অনুরোধটি পুনরায় চেষ্টা করতে পারে এবং একটি নির্দিষ্ট সংখ্যক বার চেষ্টা বা ব্যবহারকারীর মোট অপেক্ষার সময় শেষ হওয়ার পরেই কেবল ইউজার ইন্টারফেসে ত্রুটিটি প্রদর্শন করতে পারে।

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

যখন আপনি অনুরোধগুলো পুনরায় চেষ্টা করবেন, তখন র‍্যান্ডমাইজড জিটার সহ একটি এক্সপোনেনশিয়াল ব্যাকঅফ পলিসি ব্যবহার করুন। উদাহরণস্বরূপ, যদি আপনি প্রথমবার পুনরায় চেষ্টার আগে ৫ সেকেন্ড বিরতি দেন, তাহলে আপনি দ্বিতীয়বার চেষ্টার পর ১০ সেকেন্ড এবং তৃতীয়বার চেষ্টার পর ২০ সেকেন্ড বিরতি দিতে পারেন। এর ফলে প্রতিটি বিরতিতে একটি ছোট র‍্যান্ডম ডিলে যুক্ত হবে, যা একই সময়ে পুনরায় চেষ্টার সংখ্যা হঠাৎ বেড়ে যাওয়া (সিঙ্ক্রোনাস রিট্রাই স্পাইক) প্রতিরোধ করবে। এক্সপোনেনশিয়াল ব্যাকঅফ এটি নিশ্চিত করতে সাহায্য করে যে আপনি এপিআই-কে অতিরিক্ত আগ্রাসীভাবে কল করছেন না। বারবার চেষ্টা করার পরেও যদি কোনো ত্রুটি থেকে যায়, তাহলে সমস্যা সমাধানের জন্য রেসপন্স থেকে request-id লগ করে রাখুন।

বৈধতা ত্রুটি

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

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

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

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

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

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