Package google.rpc

সূচক

খারাপ অনুরোধ

ক্লায়েন্টের অনুরোধে লঙ্ঘনের বর্ণনা দেয়। এই ত্রুটির ধরণটি অনুরোধের সিনট্যাকটিক দিকগুলিতে ফোকাস করে।

ক্ষেত্র
field_violations[]

FieldViolation

ক্লায়েন্টের অনুরোধে সমস্ত লঙ্ঘনের বর্ণনা দেয়।

ক্ষেত্র লঙ্ঘন

একটি খারাপ অনুরোধ ক্ষেত্র বর্ণনা করতে ব্যবহৃত একটি বার্তার ধরণ।

ক্ষেত্র
field

string

একটি পথ যা অনুরোধের মূল অংশের একটি ক্ষেত্রের দিকে নিয়ে যায়। মানটি হবে ডট-বিচ্ছিন্ন শনাক্তকারীদের একটি ক্রম যা একটি প্রোটোকল বাফার ক্ষেত্র সনাক্ত করে।

নিম্নলিখিত বিষয়গুলি বিবেচনা করুন:

message CreateContactRequest {
  message EmailAddress {
    enum Type {
      TYPE_UNSPECIFIED = 0;
      HOME = 1;
      WORK = 2;
    }

    optional string email = 1;
    repeated EmailType type = 2;
  }

  string full_name = 1;
  repeated EmailAddress email_addresses = 2;
}

এই উদাহরণে, প্রোটো field নিম্নলিখিত মানগুলির মধ্যে একটি নিতে পারে:

  • full_name মানের লঙ্ঘনের জন্য full_name
  • প্রথম email_addresses বার্তার email ক্ষেত্রে লঙ্ঘনের জন্য email_addresses[1].email
  • তৃতীয় email_addresses বার্তায় দ্বিতীয় type মানের লঙ্ঘনের জন্য email_addresses[3].type[2] ।

JSON-এ, একই মানগুলি নিম্নরূপে উপস্থাপিত হয়:

  • fullName মানের লঙ্ঘনের জন্য fullName
  • প্রথম emailAddresses বার্তার email ক্ষেত্রে লঙ্ঘনের জন্য emailAddresses[1].email
  • তৃতীয় emailAddresses বার্তায় দ্বিতীয় type মানের লঙ্ঘনের জন্য emailAddresses[3].type[2] ।
description

string

অনুরোধের উপাদানটি কেন খারাপ তার একটি বর্ণনা।

reason

string

ফিল্ড-লেভেল ত্রুটির কারণ। এটি একটি ধ্রুবক মান যা ফিল্ড-লেভেল ত্রুটির নিকটতম কারণ চিহ্নিত করে। এটি google.rpc.ErrorInfo.domain এর সুযোগের মধ্যে FieldViolation এর ধরণটি অনন্যভাবে সনাক্ত করবে। এটি সর্বাধিক 63 টি অক্ষরের হওয়া উচিত এবং [AZ][A-Z0-9_]+[A-Z0-9] এর একটি নিয়মিত অভিব্যক্তির সাথে মেলে, যা UPPER_SNAKE_CASE কে প্রতিনিধিত্ব করে।

localized_message

LocalizedMessage

ফিল্ড-লেভেল ত্রুটির জন্য একটি স্থানীয় ত্রুটি বার্তা প্রদান করে যা API গ্রাহকের কাছে ফেরত পাঠানো নিরাপদ।

কোড

gRPC API-এর জন্য ক্যানোনিকাল ত্রুটি কোড।

কখনও কখনও একাধিক ত্রুটি কোড প্রযোজ্য হতে পারে। পরিষেবাগুলি প্রযোজ্য সবচেয়ে নির্দিষ্ট ত্রুটি কোডটি ফেরত দেবে। উদাহরণস্বরূপ, যদি উভয় কোড প্রযোজ্য হয় তবে FAILED_PRECONDITION এর চেয়ে OUT_OF_RANGE পছন্দ করুন। একইভাবে FAILED_PRECONDITION এর চেয়ে NOT_FOUND বা ALREADY_EXISTS পছন্দ করুন।

এনামস
OK

কোনও ভুল নয়; সাফল্যের সাথে ফিরে এসেছি।

HTTP ম্যাপিং: ২০০ ঠিক আছে

CANCELLED

অপারেশনটি বাতিল করা হয়েছিল, সাধারণত কলকারীর দ্বারা।

HTTP ম্যাপিং: 499 ক্লায়েন্ট ক্লোজড রিকোয়েস্ট

UNKNOWN

অজানা ত্রুটি। উদাহরণস্বরূপ, এই ত্রুটিটি তখনই ফিরে আসতে পারে যখন অন্য ঠিকানা স্থান থেকে প্রাপ্ত একটি Status মান এমন একটি ত্রুটি স্থানের অন্তর্গত যা এই ঠিকানা স্থানের অজানা। এছাড়াও, API দ্বারা উত্থাপিত ত্রুটিগুলি যা পর্যাপ্ত ত্রুটি তথ্য প্রদান করে না সেগুলি এই ত্রুটিতে রূপান্তরিত হতে পারে।

HTTP ম্যাপিং: ৫০০ অভ্যন্তরীণ সার্ভার ত্রুটি

INVALID_ARGUMENT

ক্লায়েন্ট একটি অবৈধ আর্গুমেন্ট নির্দিষ্ট করেছে। মনে রাখবেন এটি FAILED_PRECONDITION থেকে আলাদা। INVALID_ARGUMENT এমন আর্গুমেন্ট নির্দেশ করে যা সিস্টেমের অবস্থা নির্বিশেষে সমস্যাযুক্ত (যেমন, একটি ত্রুটিপূর্ণ ফাইলের নাম)।

HTTP ম্যাপিং: 400 খারাপ অনুরোধ

DEADLINE_EXCEEDED

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

HTTP ম্যাপিং: ৫০৪ গেটওয়ে টাইমআউট

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 ম্যাপিং: ৪২৯টি অনেক বেশি অনুরোধ

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

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

HTTP ম্যাপিং: ৫০০ অভ্যন্তরীণ সার্ভার ত্রুটি

UNAVAILABLE

পরিষেবাটি বর্তমানে অনুপলব্ধ। এটি সম্ভবত একটি ক্ষণস্থায়ী অবস্থা, যা ব্যাকঅফ দিয়ে পুনরায় চেষ্টা করে সংশোধন করা যেতে পারে। মনে রাখবেন যে অ-ইডেম্পটেন্ট অপারেশনগুলি পুনরায় চেষ্টা করা সবসময় নিরাপদ নয়।

FAILED_PRECONDITION , ABORTED এবং UNAVAILABLE এর মধ্যে সিদ্ধান্ত নেওয়ার জন্য উপরের নির্দেশিকাগুলি দেখুন।

HTTP ম্যাপিং: 503 পরিষেবা অনুপলব্ধ

DATA_LOSS

অপ্রত্যাশিত তথ্য ক্ষতি বা দুর্নীতি।

HTTP ম্যাপিং: ৫০০ অভ্যন্তরীণ সার্ভার ত্রুটি

ত্রুটি তথ্য

কাঠামোগত বিবরণ সহ ত্রুটির কারণ বর্ণনা করে।

"pubsub.googleapis.com" API সক্রিয় না থাকাকালীন যোগাযোগ করার সময় একটি ত্রুটির উদাহরণ:

{ "reason": "API_DISABLED"
  "domain": "googleapis.com"
  "metadata": {
    "resource": "projects/123",
    "service": "pubsub.googleapis.com"
  }
}

এই উত্তরটি ইঙ্গিত করে যে pubsub.googleapis.com API সক্রিয় নেই।

স্টক শেষ হয়ে যাওয়া কোনও অঞ্চলে স্প্যানার ইনস্ট্যান্স তৈরি করার চেষ্টা করার সময় যে ত্রুটি দেখা দেয় তার উদাহরণ:

{ "reason": "STOCKOUT"
  "domain": "spanner.googleapis.com",
  "metadata": {
    "availableRegions": "us-central1,us-east2"
  }
}
ক্ষেত্র
reason

string

ত্রুটির কারণ। এটি একটি ধ্রুবক মান যা ত্রুটির নিকটতম কারণ চিহ্নিত করে। ত্রুটির কারণগুলি ত্রুটির একটি নির্দিষ্ট ডোমেনের মধ্যে অনন্য। এটি সর্বাধিক 63 অক্ষরের হওয়া উচিত এবং [AZ][A-Z0-9_]+[A-Z0-9] এর একটি নিয়মিত অভিব্যক্তির সাথে মেলে, যা UPPER_SNAKE_CASE প্রতিনিধিত্ব করে।

domain

string

"কারণ" যে লজিক্যাল গ্রুপিংয়ের সাথে সম্পর্কিত। ত্রুটি ডোমেনটি সাধারণত সেই টুল বা পণ্যের নিবন্ধিত পরিষেবার নাম যা ত্রুটি তৈরি করে। উদাহরণ: "pubsub.googleapis.com"। যদি ত্রুটিটি কিছু সাধারণ অবকাঠামো দ্বারা তৈরি হয়, তাহলে ত্রুটি ডোমেনটি অবশ্যই একটি বিশ্বব্যাপী অনন্য মান হতে হবে যা পরিকাঠামো সনাক্ত করে। Google API অবকাঠামোর জন্য, ত্রুটি ডোমেনটি হল "googleapis.com"।

metadata

map<string, string>

এই ত্রুটি সম্পর্কে অতিরিক্ত কাঠামোগত বিবরণ।

কীগুলি অবশ্যই [az][a-zA-Z0-9-_]+ এর একটি নিয়মিত এক্সপ্রেশনের সাথে মিলবে তবে আদর্শভাবে lowerCamelCase হওয়া উচিত। এছাড়াও, তাদের দৈর্ঘ্য 64 অক্ষরের মধ্যে সীমাবদ্ধ থাকতে হবে। অতিক্রম করা সীমার বর্তমান মান সনাক্ত করার সময়, ইউনিটগুলি কীতে থাকা উচিত, মান নয়। উদাহরণস্বরূপ, {"instanceLimit": "100/request"} এর পরিবর্তে, {"instanceLimitPerRequest": "100"} হিসাবে ফেরত পাঠানো উচিত, যদি ক্লায়েন্ট একটি একক (ব্যাচ) অনুরোধে তৈরি করা যেতে পারে এমন উদাহরণের সংখ্যা অতিক্রম করে।

সাহায্য

ডকুমেন্টেশনের লিঙ্ক অথবা ব্যান্ডের বাইরের কোনও অ্যাকশন সম্পাদনের জন্য লিঙ্ক প্রদান করে।

উদাহরণস্বরূপ, যদি একটি কোটা চেক ব্যর্থ হয় যেখানে একটি ত্রুটি নির্দেশ করে যে কলিং প্রকল্পটি অ্যাক্সেস করা পরিষেবা সক্ষম করেনি, তাহলে এতে একটি URL থাকতে পারে যা বিটটি উল্টানোর জন্য ডেভেলপার কনসোলের সঠিক স্থানে সরাসরি নির্দেশ করে।

ক্ষেত্র

স্থানীয় বার্তা

একটি স্থানীয় ত্রুটি বার্তা প্রদান করে যা ব্যবহারকারীর কাছে ফেরত পাঠানো নিরাপদ যা একটি RPC ত্রুটির সাথে সংযুক্ত করা যেতে পারে।

ক্ষেত্র
locale

string

https://www.rfc-editor.org/rfc/bcp/bcp47.txt এ সংজ্ঞায়িত স্পেসিফিকেশন অনুসরণ করে ব্যবহৃত লোকেল। উদাহরণ হল: "en-US", "fr-CH", "es-MX"

message

string

উপরের লোকেলে স্থানীয়কৃত ত্রুটি বার্তা।

তথ্য অনুরোধ করুন

বাগ ফাইল করার সময় বা অন্যান্য ধরণের প্রতিক্রিয়া প্রদানের সময় ক্লায়েন্টরা যে অনুরোধটি সংযুক্ত করতে পারে তার মেটাডেটা রয়েছে।

ক্ষেত্র
request_id

string

একটি অস্বচ্ছ স্ট্রিং যা কেবলমাত্র পরিষেবাটি তৈরি করে তার দ্বারা ব্যাখ্যা করা উচিত। উদাহরণস্বরূপ, এটি পরিষেবার লগে অনুরোধগুলি সনাক্ত করতে ব্যবহার করা যেতে পারে।

serving_data

string

এই অনুরোধটি পূরণ করতে ব্যবহৃত যেকোনো ডেটা। উদাহরণস্বরূপ, একটি এনক্রিপ্ট করা স্ট্যাক ট্রেস যা ডিবাগিংয়ের জন্য পরিষেবা প্রদানকারীর কাছে ফেরত পাঠানো যেতে পারে।

অবস্থা

Status টাইপ একটি লজিক্যাল এরর মডেলকে সংজ্ঞায়িত করে যা REST API এবং RPC API সহ বিভিন্ন প্রোগ্রামিং পরিবেশের জন্য উপযুক্ত। এটি gRPC দ্বারা ব্যবহৃত হয়। প্রতিটি Status বার্তায় তিনটি ডেটা থাকে: ত্রুটি কোড, ত্রুটি বার্তা এবং ত্রুটির বিবরণ।

এই ত্রুটি মডেল এবং এটির সাথে কীভাবে কাজ করবেন সে সম্পর্কে আপনি API ডিজাইন গাইডে আরও জানতে পারবেন।

ক্ষেত্র
code

int32

স্ট্যাটাস কোড, যা google.rpc.Code এর একটি enum মান হওয়া উচিত।

message

string

ডেভেলপার-মুখোমুখি ত্রুটির বার্তা, যা ইংরেজিতে হওয়া উচিত। ব্যবহারকারী-মুখোমুখি যেকোনো ত্রুটির বার্তা স্থানীয়করণ করে google.rpc.Status.details ক্ষেত্রে পাঠানো উচিত, অথবা ক্লায়েন্ট দ্বারা স্থানীয়করণ করা উচিত।

details[]

Any

ত্রুটির বিবরণ বহনকারী বার্তাগুলির একটি তালিকা। API গুলির ব্যবহারের জন্য বার্তার ধরণের একটি সাধারণ সেট রয়েছে।