কখনও কখনও একাধিক ত্রুটি কোড প্রযোজ্য হতে পারে. পরিষেবাগুলি প্রযোজ্য সবচেয়ে নির্দিষ্ট ত্রুটি কোডটি ফেরত দেবে। উদাহরণস্বরূপ, FAILED_PRECONDITION এর চেয়ে OUT_OF_RANGE পছন্দ করুন যদি উভয় কোডই প্রযোজ্য হয়। একইভাবে FAILED_PRECONDITION এর চেয়ে NOT_FOUND বা ALREADY_EXISTS পছন্দ করুন।
Enums
OK
একটি ত্রুটি নয়; সাফল্য ফিরে এসেছে।
HTTP ম্যাপিং: 200 ঠিক আছে
CANCELLED
অপারেশনটি বাতিল করা হয়েছে, সাধারণত কলার দ্বারা।
HTTP ম্যাপিং: 499 ক্লায়েন্ট ক্লোজড অনুরোধ
UNKNOWN
অজানা ত্রুটি. উদাহরণস্বরূপ, এই ত্রুটিটি ফেরত দেওয়া হতে পারে যখন অন্য ঠিকানা স্থান থেকে প্রাপ্ত একটি Status মান একটি ত্রুটি স্থানের অন্তর্গত হয় যা এই ঠিকানার স্থানটিতে পরিচিত নয়। এছাড়াও API-এর দ্বারা উত্থাপিত ত্রুটিগুলি যেগুলি যথেষ্ট ত্রুটির তথ্য ফেরত দেয় না সেগুলি এই ত্রুটিতে রূপান্তরিত হতে পারে৷
HTTP ম্যাপিং: 500 অভ্যন্তরীণ সার্ভার ত্রুটি
INVALID_ARGUMENT
ক্লায়েন্ট একটি অবৈধ যুক্তি নির্দিষ্ট করেছে৷ মনে রাখবেন যে এটি FAILED_PRECONDITION থেকে পৃথক। INVALID_ARGUMENT যুক্তিগুলি নির্দেশ করে যেগুলি সিস্টেমের অবস্থা নির্বিশেষে সমস্যাযুক্ত (যেমন, একটি বিকৃত ফাইলের নাম)।
HTTP ম্যাপিং: 400 খারাপ অনুরোধ
DEADLINE_EXCEEDED
অপারেশন শেষ হওয়ার আগেই সময়সীমা শেষ হয়ে গেছে। সিস্টেমের অবস্থা পরিবর্তন করে এমন অপারেশনগুলির জন্য, অপারেশনটি সফলভাবে সম্পন্ন হলেও এই ত্রুটিটি ফেরত দেওয়া হতে পারে। উদাহরণস্বরূপ, একটি সার্ভার থেকে একটি সফল প্রতিক্রিয়ার সময়সীমা শেষ হওয়ার জন্য যথেষ্ট দেরি হতে পারে।
HTTP ম্যাপিং: 504 গেটওয়ে টাইমআউট
NOT_FOUND
কিছু অনুরোধ করা সত্তা (যেমন, ফাইল বা ডিরেক্টরি) পাওয়া যায়নি।
সার্ভার ডেভেলপারদের জন্য নোট: যদি ক্রমাগত বৈশিষ্ট্য রোলআউট বা অনথিভুক্ত অনুমোদিত তালিকার মতো সম্পূর্ণ শ্রেণীর ব্যবহারকারীদের জন্য একটি অনুরোধ অস্বীকার করা হয়, NOT_FOUND ব্যবহার করা হতে পারে। যদি ব্যবহারকারীদের একটি শ্রেণীর মধ্যে কিছু ব্যবহারকারীর জন্য অনুরোধ অস্বীকার করা হয়, যেমন ব্যবহারকারী-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ, PERMISSION_DENIED অবশ্যই ব্যবহার করা উচিত।
HTTP ম্যাপিং: 404 পাওয়া যায়নি
ALREADY_EXISTS
একটি ক্লায়েন্ট তৈরি করার চেষ্টা করেছে এমন সত্তা (যেমন, ফাইল বা ডিরেক্টরি) ইতিমধ্যেই বিদ্যমান।
HTTP ম্যাপিং: 409 কনফ্লিক্ট
PERMISSION_DENIED
কলার নির্দিষ্ট অপারেশন চালানোর অনুমতি নেই. PERMISSION_DENIED কিছু রিসোর্স শেষ করার কারণে প্রত্যাখ্যানের জন্য ব্যবহার করা উচিত নয় (সেই ত্রুটিগুলির জন্য পরিবর্তে RESOURCE_EXHAUSTED ব্যবহার করুন)। কলকারীকে সনাক্ত করা না গেলে PERMISSION_DENIED ব্যবহার করা উচিত নয় (সেই ত্রুটিগুলির জন্য UNAUTHENTICATED ব্যবহার করুন)। এই ত্রুটি কোডটি বোঝায় না যে অনুরোধটি বৈধ বা অনুরোধ করা সত্তা বিদ্যমান বা অন্যান্য পূর্ব-শর্তগুলি সন্তুষ্ট করে৷
HTTP ম্যাপিং: 403 নিষিদ্ধ
UNAUTHENTICATED
অনুরোধটির অপারেশনের জন্য বৈধ প্রমাণীকরণ শংসাপত্র নেই৷
HTTP ম্যাপিং: 401 অননুমোদিত
RESOURCE_EXHAUSTED
কিছু রিসোর্স শেষ হয়ে গেছে, সম্ভবত একটি প্রতি-ব্যবহারকারী কোটা, অথবা সম্ভবত পুরো ফাইল সিস্টেমটি স্থানের বাইরে।
HTTP ম্যাপিং: 429 অনেক বেশি অনুরোধ
FAILED_PRECONDITION
অপারেশনটি প্রত্যাখ্যান করা হয়েছে কারণ অপারেশনটি কার্যকর করার জন্য সিস্টেমটি প্রয়োজনীয় অবস্থায় নেই৷ উদাহরণস্বরূপ, যে ডিরেক্টরিটি মুছে ফেলা হবে সেটি খালি নয়, একটি অ-ডিরেক্টরিতে একটি rmdir অপারেশন প্রয়োগ করা হয়, ইত্যাদি।
পরিষেবা বাস্তবায়নকারীরা FAILED_PRECONDITION , ABORTED , এবং UNAVAILABLE মধ্যে সিদ্ধান্ত নিতে নিম্নলিখিত নির্দেশিকাগুলি ব্যবহার করতে পারেন: (a) যদি ক্লায়েন্ট শুধুমাত্র ব্যর্থ কলের জন্য পুনরায় চেষ্টা করতে পারে তবে UNAVAILABLE ব্যবহার করুন৷ (b) ABORTED ব্যবহার করুন যদি ক্লায়েন্ট একটি উচ্চ স্তরে পুনরায় চেষ্টা করে। উদাহরণস্বরূপ, যখন একটি ক্লায়েন্ট-নির্দিষ্ট পরীক্ষা-এবং-সেট ব্যর্থ হয়, তখন ক্লায়েন্টকে একটি পঠন-সংশোধন-লেখার ক্রম পুনরায় চালু করা উচিত। (c) FAILED_PRECONDITION ব্যবহার করুন যদি সিস্টেমের অবস্থা স্পষ্টভাবে ঠিক না হওয়া পর্যন্ত ক্লায়েন্ট পুনরায় চেষ্টা না করে। উদাহরণস্বরূপ, যদি একটি "rmdir" ব্যর্থ হয় কারণ ডিরেক্টরিটি খালি নয়, তাহলে FAILED_PRECONDITION ফেরত দেওয়া উচিত কারণ ক্লায়েন্টের পুনরায় চেষ্টা করা উচিত নয় যতক্ষণ না ফাইলগুলি ডিরেক্টরি থেকে মুছে ফেলা হয়।
HTTP ম্যাপিং: 400 খারাপ অনুরোধ
ABORTED
অপারেশনটি স্থগিত করা হয়েছিল, সাধারণত একটি সিকোয়েন্সার চেক ব্যর্থতা বা লেনদেন বাতিলের মতো একযোগে সমস্যার কারণে।
FAILED_PRECONDITION , ABORTED , এবং UNAVAILABLE মধ্যে সিদ্ধান্ত নেওয়ার জন্য উপরের নির্দেশিকাগুলি দেখুন৷
HTTP ম্যাপিং: 409 কনফ্লিক্ট
OUT_OF_RANGE
অপারেশনটি বৈধ পরিসীমা অতিক্রম করার চেষ্টা করা হয়েছে৷ যেমন, ফাইলের শেষের শেষের দিকে চাওয়া বা পড়া।
INVALID_ARGUMENT বিপরীতে, এই ত্রুটিটি এমন একটি সমস্যা নির্দেশ করে যা সিস্টেমের অবস্থা পরিবর্তন হলে ঠিক করা যেতে পারে। উদাহরণস্বরূপ, একটি 32-বিট ফাইল সিস্টেম INVALID_ARGUMENT তৈরি করবে যদি এমন একটি অফসেটে পড়তে বলা হয় যা [0,2^32-1] রেঞ্জের মধ্যে নেই, কিন্তু বর্তমানের অতীতের অফসেট থেকে পড়তে বলা হলে এটি OUT_OF_RANGE তৈরি করবে ফাইলের আকার।
FAILED_PRECONDITION এবং OUT_OF_RANGE মধ্যে মোটামুটি ওভারল্যাপ আছে। যখন এটি প্রযোজ্য হয় তখন আমরা OUT_OF_RANGE (আরো নির্দিষ্ট ত্রুটি) ব্যবহার করার পরামর্শ দিই যাতে কলকারীরা একটি স্থানের মাধ্যমে পুনরাবৃত্তি করে তারা সহজেই একটি OUT_OF_RANGE ত্রুটি সনাক্ত করতে পারে যখন সেগুলি সম্পন্ন হয়।
HTTP ম্যাপিং: 400 খারাপ অনুরোধ
UNIMPLEMENTED
অপারেশনটি বাস্তবায়িত হয় না বা এই পরিষেবাতে সমর্থিত/সক্ষম নয়।
HTTP ম্যাপিং: 501 বাস্তবায়িত হয়নি
INTERNAL
অভ্যন্তরীণ ত্রুটি. এর মানে হল যে অন্তর্নিহিত সিস্টেমের দ্বারা প্রত্যাশিত কিছু invariants ভেঙে গেছে। এই ত্রুটি কোড গুরুতর ত্রুটির জন্য সংরক্ষিত.
HTTP ম্যাপিং: 500 অভ্যন্তরীণ সার্ভার ত্রুটি
UNAVAILABLE
পরিষেবাটি বর্তমানে অনুপলব্ধ৷ এটি সম্ভবত একটি ক্ষণস্থায়ী অবস্থা, যা ব্যাকঅফের সাথে পুনরায় চেষ্টা করে সংশোধন করা যেতে পারে। মনে রাখবেন যে অ-অদম্য অপারেশন পুনরায় চেষ্টা করা সবসময় নিরাপদ নয়।
FAILED_PRECONDITION , ABORTED , এবং UNAVAILABLE মধ্যে সিদ্ধান্ত নেওয়ার জন্য উপরের নির্দেশিকাগুলি দেখুন৷
HTTP ম্যাপিং: 503 পরিষেবা অনুপলব্ধ৷
DATA_LOSS
পুনরুদ্ধারযোগ্য ডেটা ক্ষতি বা দুর্নীতি।
HTTP ম্যাপিং: 500 অভ্যন্তরীণ সার্ভার ত্রুটি
স্ট্যাটাস
Status টাইপ একটি লজিক্যাল ত্রুটি মডেলকে সংজ্ঞায়িত করে যা REST API এবং RPC API সহ বিভিন্ন প্রোগ্রামিং পরিবেশের জন্য উপযুক্ত। এটি gRPC দ্বারা ব্যবহৃত হয়। প্রতিটি Status বার্তায় তিনটি টুকরো ডেটা থাকে: ত্রুটি কোড, ত্রুটি বার্তা এবং ত্রুটির বিবরণ।
আপনি API ডিজাইন গাইডে এই ত্রুটি মডেল এবং এটির সাথে কীভাবে কাজ করবেন সে সম্পর্কে আরও জানতে পারেন।
ক্ষেত্র
code
int32
স্ট্যাটাস কোড, যা google.rpc.Code এর একটি enum মান হওয়া উচিত।
message
string
একটি বিকাশকারী-মুখী ত্রুটি বার্তা, যা ইংরেজিতে হওয়া উচিত। যেকোন ব্যবহারকারী-মুখী ত্রুটি বার্তা স্থানীয়করণ করা উচিত এবং google.rpc.Status.details ক্ষেত্রে পাঠানো উচিত, অথবা ক্লায়েন্ট দ্বারা স্থানীয়করণ করা উচিত।
[[["সহজে বোঝা যায়","easyToUnderstand","thumb-up"],["আমার সমস্যার সমাধান হয়েছে","solvedMyProblem","thumb-up"],["অন্যান্য","otherUp","thumb-up"]],[["এতে আমার প্রয়োজনীয় তথ্য নেই","missingTheInformationINeed","thumb-down"],["খুব জটিল / অনেক ধাপ","tooComplicatedTooManySteps","thumb-down"],["পুরনো","outOfDate","thumb-down"],["অনুবাদ সংক্রান্ত সমস্যা","translationIssue","thumb-down"],["নমুনা / কোড সংক্রান্ত সমস্যা","samplesCodeIssue","thumb-down"],["অন্যান্য","otherDown","thumb-down"]],["2025-01-22 UTC-তে শেষবার আপডেট করা হয়েছে।"],[[["`google.rpc.Code` defines canonical error codes for gRPC APIs, mapping to HTTP status codes for easy integration."],["`google.rpc.Status` provides a structured error model with a code, message, and optional details for richer error handling."],["Developers should prioritize returning the most specific error code from `google.rpc.Code` that applies to the situation."],["Error messages within `google.rpc.Status` are intended for developers and should be in English, while user-facing messages should be handled separately."]]],["The document outlines the `Code` enum and `Status` message for gRPC APIs. `Code` defines canonical error codes, guiding services to use the most specific applicable code (e.g., `OUT_OF_RANGE`, `NOT_FOUND`). Each code, like `OK`, `CANCELLED`, or `INTERNAL`, has an HTTP mapping. `Status` is a logical error model with three data pieces: a numeric error `code`, a developer-facing `message`, and `details` for structured error data.\n"]]