Package google.rpc

इंडेक्स

BadRequest

क्लाइंट के अनुरोध में हुए उल्लंघनों के बारे में बताता है. इस तरह की गड़बड़ी में, अनुरोध के सिंटैक्टिक पहलुओं पर फ़ोकस किया जाता है.

फ़ील्ड
field_violations[]

FieldViolation

इसमें क्लाइंट के अनुरोध में हुए सभी उल्लंघनों के बारे में बताया जाता है.

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[0].email
  • तीसरे email_addresses मैसेज में, दूसरी type वैल्यू के उल्लंघन के लिए email_addresses[2].type[1].

JSON में, एक जैसी वैल्यू को इस तरह दिखाया जाता है:

  • fullName वैल्यू के उल्लंघन के लिए fullName
  • emailAddresses मैसेज के email फ़ील्ड में हुए उल्लंघन के लिए emailAddresses[0].email
  • तीसरे emailAddresses मैसेज में, दूसरी type वैल्यू के उल्लंघन के लिए emailAddresses[2].type[1].
description

string

अनुरोध एलिमेंट के खराब होने की वजह के बारे में जानकारी.
reason

string

फ़ील्ड-लेवल की गड़बड़ी की वजह. यह एक ऐसी वैल्यू है जो फ़ील्ड-लेवल की गड़बड़ी की मुख्य वजह की पहचान करती है. इससे google.rpc.ErrorInfo.domain के स्कोप में, FieldViolation के टाइप की खास तौर पर पहचान होनी चाहिए. यह ज़्यादा से ज़्यादा 63 वर्णों का होना चाहिए. साथ ही, यह [A-Z][A-Z0-9_]+[A-Z0-9] के रेगुलर एक्सप्रेशन से मेल खाना चाहिए. यह UPPER_SNAKE_CASE को दिखाता है.
localized_message

LocalizedMessage

यह फ़ील्ड-लेवल की गड़बड़ियों के लिए, स्थानीय भाषा में गड़बड़ी का मैसेज दिखाता है. इसे एपीआई का इस्तेमाल करने वाले व्यक्ति को दिखाया जा सकता है.

कोड

gRPC API के लिए कैननिकल गड़बड़ी कोड.

कभी-कभी एक से ज़्यादा गड़बड़ी कोड लागू हो सकते हैं. सेवाओं को सबसे सटीक गड़बड़ी कोड दिखाना चाहिए. उदाहरण के लिए, अगर दोनों कोड लागू होते हैं, तो FAILED_PRECONDITION के बजाय OUT_OF_RANGE को प्राथमिकता दें. इसी तरह, FAILED_PRECONDITION के बजाय NOT_FOUND या ALREADY_EXISTS को प्राथमिकता दें.

Enums
OK

यह कोई गड़बड़ी नहीं है. यह अनुरोध पूरा होने पर दिखता है.

एचटीटीपी मैपिंग: 200 ठीक है
CANCELLED

कार्रवाई रद्द कर दी गई थी. आम तौर पर, ऐसा कॉल करने वाला व्यक्ति करता है.

एचटीटीपी मैपिंग: 499 अनुरोध की प्रोसेस होने के दौरान क्लाइंट ने कनेक्शन बंद कर दिया
UNKNOWN

ऐसी गड़बड़ी जिसकी कोई जानकारी नहीं है. उदाहरण के लिए, यह गड़बड़ी तब दिख सकती है, जब किसी दूसरे पते की जगह से मिली Status वैल्यू, किसी ऐसी गड़बड़ी की जगह से जुड़ी हो जिसके बारे में इस पते की जगह पर जानकारी न हो. इसके अलावा, ऐसे एपीआई से मिली गड़बड़ियों को भी इस गड़बड़ी में बदला जा सकता है जो गड़बड़ी की पूरी जानकारी नहीं देते.

HTTP मैपिंग: 500 सर्वर में गड़बड़ी
INVALID_ARGUMENT

क्लाइंट ने एक अमान्य तर्क बताया. ध्यान दें कि यह FAILED_PRECONDITION से अलग है. INVALID_ARGUMENT से ऐसे तर्कों का पता चलता है जिनमें सिस्टम की स्थिति से कोई फ़र्क़ नहीं पड़ता. जैसे, फ़ाइल का गलत नाम.

एचटीटीपी मैपिंग: 400 गलत अनुरोध
DEADLINE_EXCEEDED

कार्रवाई पूरी होने से पहले ही समयसीमा खत्म हो गई. सिस्टम की स्थिति में बदलाव करने वाली कार्रवाइयों के लिए, यह गड़बड़ी तब भी दिख सकती है, जब कार्रवाई पूरी हो गई हो. उदाहरण के लिए, किसी सर्वर से मिला जवाब, समयसीमा खत्म होने के बाद मिला हो.

एचटीटीपी मैपिंग: 504 गेटवे टाइम आउट
NOT_FOUND

अनुरोध की गई कुछ इकाई (जैसे, फ़ाइल या डायरेक्ट्री) नहीं मिली.

सर्वर डेवलपर के लिए सूचना: अगर उपयोगकर्ताओं के पूरे ग्रुप के लिए किसी अनुरोध को अस्वीकार कर दिया जाता है, तो NOT_FOUND का इस्तेमाल किया जा सकता है. जैसे, सुविधा को धीरे-धीरे रोल आउट करना या बिना दस्तावेज़ वाली अनुमति वाली सूची. अगर उपयोगकर्ताओं के किसी ग्रुप के कुछ सदस्यों के लिए, ऐक्सेस का अनुरोध अस्वीकार कर दिया जाता है, तो PERMISSION_DENIED का इस्तेमाल करना ज़रूरी है. जैसे, उपयोगकर्ता के हिसाब से ऐक्सेस कंट्रोल.

एचटीटीपी मैपिंग: 404 नहीं मिला
ALREADY_EXISTS

क्लाइंट ने जिस इकाई को बनाने की कोशिश की है (जैसे, फ़ाइल या डायरेक्ट्री), वह पहले से मौजूद है.

एचटीटीपी मैपिंग: 409 गड़बड़ी
PERMISSION_DENIED

कॉलर के पास, तय की गई कार्रवाई को पूरा करने की अनुमति नहीं है. PERMISSION_DENIED का इस्तेमाल, किसी संसाधन के खत्म होने की वजह से अस्वीकार किए गए अनुरोधों के लिए नहीं किया जाना चाहिए. इसके बजाय, उन गड़बड़ियों के लिए RESOURCE_EXHAUSTED का इस्तेमाल करें. अगर कॉलर की पहचान नहीं की जा सकती, तो PERMISSION_DENIED का इस्तेमाल नहीं किया जाना चाहिए. इसके बजाय, उन गड़बड़ियों के लिए UNAUTHENTICATED का इस्तेमाल करें. इस गड़बड़ी कोड का मतलब यह नहीं है कि अनुरोध मान्य है या अनुरोध की गई इकाई मौजूद है या अन्य ज़रूरी शर्तें पूरी करती है.

एचटीटीपी मैपिंग: 403 अनुमति नहीं है
UNAUTHENTICATED

अनुरोध में, कार्रवाई के लिए पुष्टि करने वाले मान्य क्रेडेंशियल नहीं हैं.

एचटीटीपी मैपिंग: 401 Unauthorized
RESOURCE_EXHAUSTED

कुछ संसाधन खत्म हो गए हैं. ऐसा हो सकता है कि हर उपयोगकर्ता के लिए तय किया गया कोटा खत्म हो गया हो या पूरे फ़ाइल सिस्टम में जगह न बची हो.

एचटीटीपी मैपिंग: 429 कई बार अनुरोध किया गया
FAILED_PRECONDITION

इस कार्रवाई को अस्वीकार कर दिया गया है, क्योंकि सिस्टम उस स्थिति में नहीं है जिसमें कार्रवाई की जा सकती है. उदाहरण के लिए, मिटाई जाने वाली डायरेक्ट्री खाली नहीं है, rmdir ऑपरेशन को किसी डायरेक्ट्री पर लागू नहीं किया गया है वगैरह.

सेवा लागू करने वाले लोग या कंपनियां, FAILED_PRECONDITION, ABORTED, और UNAVAILABLE में से किसी एक को चुनने के लिए, इन दिशा-निर्देशों का इस्तेमाल कर सकती हैं: (a) अगर क्लाइंट सिर्फ़ फ़ेल हुए कॉल को फिर से आज़मा सकता है, तो UNAVAILABLE का इस्तेमाल करें. (b) अगर क्लाइंट को ज़्यादा लेवल पर फिर से कोशिश करनी चाहिए, तो ABORTED का इस्तेमाल करें. उदाहरण के लिए, जब क्लाइंट की ओर से तय किया गया टेस्ट-एंड-सेट फ़ेल हो जाता है, तो इसका मतलब है कि क्लाइंट को read-modify-write सीक्वेंस को फिर से शुरू करना चाहिए. (c) अगर क्लाइंट को तब तक फिर से कोशिश नहीं करनी चाहिए, जब तक सिस्टम की स्थिति ठीक नहीं हो जाती, तो FAILED_PRECONDITION का इस्तेमाल करें. उदाहरण के लिए, अगर कोई डायरेक्ट्री खाली न होने की वजह से "rmdir" काम नहीं करता है, तो FAILED_PRECONDITION को वापस कर दिया जाना चाहिए. ऐसा इसलिए, क्योंकि क्लाइंट को तब तक फिर से कोशिश नहीं करनी चाहिए, जब तक डायरेक्ट्री से फ़ाइलें नहीं मिटा दी जातीं.

एचटीटीपी मैपिंग: 400 गलत अनुरोध
ABORTED

कार्रवाई को बीच में ही रद्द कर दिया गया. आम तौर पर, ऐसा एक साथ कई अनुरोध आने की वजह से होता है. जैसे, सीक्वेंसर की जांच पूरी न हो पाना या लेन-देन रद्द हो जाना.

FAILED_PRECONDITION, ABORTED, और UNAVAILABLE में से किसी एक को चुनने के लिए, ऊपर दिए गए दिशा-निर्देश देखें.

एचटीटीपी मैपिंग: 409 गड़बड़ी
OUT_OF_RANGE

मान्य सीमा से बाहर जाकर कार्रवाई करने की कोशिश की गई. उदाहरण के लिए, फ़ाइल के आखिर से आगे की जानकारी पाना या पढ़ना.

INVALID_ARGUMENT के उलट, इस गड़बड़ी से ऐसी समस्या का पता चलता है जिसे सिस्टम की स्थिति बदलने पर ठीक किया जा सकता है. उदाहरण के लिए, अगर किसी 32-बिट फ़ाइल सिस्टम से ऐसे ऑफ़सेट पर पढ़ने के लिए कहा जाता है जो [0,2^32-1] रेंज में नहीं है, तो वह INVALID_ARGUMENT जनरेट करेगा. हालांकि, अगर उससे मौजूदा फ़ाइल साइज़ से ज़्यादा ऑफ़सेट पर पढ़ने के लिए कहा जाता है, तो वह OUT_OF_RANGE जनरेट करेगा.

FAILED_PRECONDITION और OUT_OF_RANGE के बीच काफ़ी ओवरलैप है. हमारा सुझाव है कि जब OUT_OF_RANGE (ज़्यादा सटीक गड़बड़ी) लागू हो, तब इसका इस्तेमाल करें. इससे कॉल करने वाले लोग, स्पेस में बार-बार होने वाली OUT_OF_RANGE गड़बड़ी को आसानी से ढूंढ सकते हैं. साथ ही, यह पता लगा सकते हैं कि गड़बड़ी कब ठीक हुई.

एचटीटीपी मैपिंग: 400 गलत अनुरोध
UNIMPLEMENTED

यह ऑपरेशन लागू नहीं किया गया है या इस सेवा में काम नहीं करता/चालू नहीं है.

एचटीटीपी मैपिंग: 501 अनुरोध पूरा करने के लिए सुविधाएं मौजूद नहीं हैं
INTERNAL

सिस्टम में गड़बड़ियां. इसका मतलब है कि सिस्टम के कुछ इनवेरिएंट टूट गए हैं. यह गड़बड़ी कोड, गंभीर गड़बड़ियों के लिए रिज़र्व किया गया है.

HTTP मैपिंग: 500 सर्वर में गड़बड़ी
UNAVAILABLE

फ़िलहाल, सेवा उपलब्ध नहीं है. यह एक अस्थायी समस्या है. कुछ समय बाद फिर से कोशिश करने पर, इसे ठीक किया जा सकता है. ध्यान दें कि नॉन-आइटमपोटेंट ऑपरेशनों को फिर से आज़माना हमेशा सुरक्षित नहीं होता.

FAILED_PRECONDITION, ABORTED, और UNAVAILABLE में से किसी एक को चुनने के लिए, ऊपर दिए गए दिशा-निर्देश देखें.

एचटीटीपी मैपिंग: 503 सेवा उपलब्ध नहीं है
DATA_LOSS

डेटा को वापस नहीं पाया जा सकता या डेटा खराब हो गया.

HTTP मैपिंग: 500 सर्वर में गड़बड़ी

ErrorInfo

इसमें गड़बड़ी की वजह के बारे में स्ट्रक्चर्ड जानकारी दी गई है.

जब "pubsub.googleapis.com" एपीआई चालू नहीं होता है, तब उससे संपर्क करने पर गड़बड़ी का उदाहरण:

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

इस रिस्पॉन्स से पता चलता है कि pubsub.googleapis.com API चालू नहीं है.

किसी ऐसे इलाके में Spanner इंस्टेंस बनाने की कोशिश करने पर मिलने वाली गड़बड़ी का उदाहरण जहां यह सुविधा स्टॉक में नहीं है:

{ "reason": "STOCKOUT"
  "domain": "spanner.googleapis.com",
  "metadata": {
    "availableRegions": "us-central1,us-east2"
  }
}
फ़ील्ड
reason

string

गड़बड़ी की वजह. यह एक ऐसी वैल्यू होती है जो गड़बड़ी की मुख्य वजह की पहचान करती है. गड़बड़ी की वजहें, गड़बड़ियों के किसी खास डोमेन में यूनीक होती हैं. यह ज़्यादा से ज़्यादा 63 वर्णों का होना चाहिए. साथ ही, यह [A-Z][A-Z0-9_]+[A-Z0-9] के रेगुलर एक्सप्रेशन से मेल खाना चाहिए. यह UPPER_SNAKE_CASE को दिखाता है.
domain

string

लॉजिकल ग्रुपिंग, जिससे "reason" एट्रिब्यूट की वैल्यू जुड़ी है. गड़बड़ी का डोमेन आम तौर पर, उस टूल या प्रॉडक्ट का रजिस्टर किया गया सेवा नाम होता है जिससे गड़बड़ी जनरेट होती है. उदाहरण: "pubsub.googleapis.com". अगर गड़बड़ी किसी सामान्य इन्फ़्रास्ट्रक्चर की वजह से जनरेट हुई है, तो गड़बड़ी का डोमेन एक ऐसी वैल्यू होनी चाहिए जो दुनिया भर में यूनीक हो और इन्फ़्रास्ट्रक्चर की पहचान करती हो. Google API इन्फ़्रास्ट्रक्चर के लिए, गड़बड़ी वाला डोमेन "googleapis.com" है.
metadata

map<string, string>

इस गड़बड़ी के बारे में स्ट्रक्चर्ड फ़ॉर्मैट में ज़्यादा जानकारी.

कुंजियां, [a-z][a-zA-Z0-9-_]+ के रेगुलर एक्सप्रेशन से मेल खानी चाहिए. हालांकि, इन्हें lowerCamelCase में होना चाहिए. साथ ही, इनकी लंबाई 64 वर्णों से ज़्यादा नहीं होनी चाहिए. सीमा से ज़्यादा वैल्यू की पहचान करते समय, यूनिट को वैल्यू में नहीं, बल्कि कुंजी में शामिल किया जाना चाहिए. उदाहरण के लिए, अगर क्लाइंट एक अनुरोध में बनाए जा सकने वाले इंस्टेंस की संख्या से ज़्यादा इंस्टेंस बनाता है, तो {"instanceLimit": "100/request"} के बजाय {"instanceLimitPerRequest": "100"} को वापस भेजा जाना चाहिए.

सहायता

दस्तावेज़ों के लिंक या आउट ऑफ़ बैंड कार्रवाई करने के लिए लिंक उपलब्ध कराता है.

उदाहरण के लिए, अगर कोटा की जांच में गड़बड़ी हुई है और गड़बड़ी से पता चलता है कि कॉल करने वाले प्रोजेक्ट ने ऐक्सेस की गई सेवा चालू नहीं की है, तो इसमें एक ऐसा यूआरएल शामिल हो सकता है जो डेवलपर कंसोल में सीधे उस जगह पर ले जाता है जहां बिट को फ़्लिप किया जा सकता है.

फ़ील्ड

LocalizedMessage

यह फ़ंक्शन, स्थानीय भाषा में गड़बड़ी का ऐसा मैसेज दिखाता है जिसे उपयोगकर्ता को दिखाया जा सकता है. इसे आरपीसी की गड़बड़ी से जोड़ा जा सकता है.

फ़ील्ड
locale

string

https://www.rfc-editor.org/rfc/bcp/bcp47.txt पर दिए गए स्पेसिफ़िकेशन के मुताबिक इस्तेमाल की गई भाषा. उदाहरण के लिए: "en-US", "fr-CH", "es-MX"
message

string

ऊपर दी गई स्थानीय भाषा में गड़बड़ी का मैसेज.

RequestInfo

इस कुकी में अनुरोध के बारे में मेटाडेटा होता है. क्लाइंट, गड़बड़ी की शिकायत करते समय या अन्य तरह का सुझाव/राय देते समय इसे अटैच कर सकते हैं.

फ़ील्ड
request_id

string

यह एक ओपेक स्ट्रिंग है. इसका मतलब सिर्फ़ इसे जनरेट करने वाली सेवा को पता होना चाहिए. उदाहरण के लिए, इसका इस्तेमाल सेवा के लॉग में अनुरोधों की पहचान करने के लिए किया जा सकता है.
serving_data

string

इस अनुरोध को पूरा करने के लिए इस्तेमाल किया गया कोई भी डेटा. उदाहरण के लिए, एन्क्रिप्ट (सुरक्षित) किया गया स्टैक ट्रेस, जिसे डीबग करने के लिए सेवा देने वाले व्यक्ति या कंपनी को वापस भेजा जा सकता है.

स्थिति

Status टाइप, लॉजिकल गड़बड़ी का एक ऐसा मॉडल तय करता है जो अलग-अलग प्रोग्रामिंग एनवायरमेंट के लिए सही होता है. इनमें REST API और RPC API शामिल हैं. इसका इस्तेमाल gRPC करता है. हर Status मैसेज में तीन तरह का डेटा होता है: गड़बड़ी का कोड, गड़बड़ी का मैसेज, और गड़बड़ी की जानकारी.

इस गड़बड़ी के मॉडल और इसके साथ काम करने के तरीके के बारे में ज़्यादा जानने के लिए, एपीआई डिज़ाइन गाइड पढ़ें.

फ़ील्ड
code

int32

स्टेटस कोड, जो google.rpc.Code की enum वैल्यू होनी चाहिए.
message

string

डेवलपर को दिखने वाला गड़बड़ी का मैसेज, जो अंग्रेज़ी में होना चाहिए. उपयोगकर्ता को दिखने वाली गड़बड़ी के किसी भी मैसेज को स्थानीय भाषा में होना चाहिए. साथ ही, उसे google.rpc.Status.details फ़ील्ड में भेजा जाना चाहिए या क्लाइंट की ओर से स्थानीय भाषा में होना चाहिए.
details[]

Any

मैसेज की सूची, जिसमें गड़बड़ी की जानकारी होती है. एपीआई के इस्तेमाल के लिए, मैसेज टाइप का एक सामान्य सेट होता है.