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[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 वर्णों का होना चाहिए. साथ ही, यह [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 OK
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 में से किसी एक को चुनने के लिए, ऊपर दिए गए दिशा-निर्देश देखें.

HTTP मैपिंग: 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

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

PreconditionFailure

इससे पता चलता है कि कौनसी ज़रूरी शर्तें पूरी नहीं हुई हैं.

उदाहरण के लिए, अगर किसी आरपीसी को सेवा की शर्तों को स्वीकार करने की ज़रूरत है और वह ऐसा नहीं कर पाती है, तो PreconditionFailure मैसेज में सेवा की शर्तों के उल्लंघन की जानकारी दी जा सकती है.

फ़ील्ड
violations[]

Violation

इसमें, शर्तों के उल्लंघन से जुड़ी सभी जानकारी होती है.

मैच की नीतियों का उल्लंघन

इस मैसेज टाइप का इस्तेमाल, किसी एक पूर्व शर्त के पूरा न होने की जानकारी देने के लिए किया जाता है.

फ़ील्ड
type

string

PreconditionFailure का टाइप. हमारा सुझाव है कि सेवा से जुड़े एनम टाइप का इस्तेमाल करके, शर्तों के उल्लंघन से जुड़े विषयों के बारे में बताएं. उदाहरण के लिए, "सेवा की शर्तों का उल्लंघन" के लिए "TOS".
subject

string

टाइप के हिसाब से, वह विषय जो पूरा नहीं किया जा सका. उदाहरण के लिए, "google.com/cloud" से पता चलेगा कि "TOS" टाइप के लिए, सेवा की किन शर्तों का रेफ़रंस दिया जा रहा है.
description

string

पहले से तय की गई शर्त पूरी न होने के बारे में जानकारी. डेवलपर इस जानकारी का इस्तेमाल करके, गड़बड़ी को ठीक करने का तरीका जान सकते हैं.

उदाहरण के लिए: "सेवा की शर्तें स्वीकार नहीं की गई हैं".

QuotaFailure

यह बताता है कि कोटा की जांच क्यों नहीं की जा सकी.

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

कोटा पूरा न होने की समस्या को हल करने के बारे में ज़्यादा जानकारी के लिए, RetryInfo और Help टाइप भी देखें.

फ़ील्ड
violations[]

Violation

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

मैच की नीतियों का उल्लंघन

इस मैसेज टाइप का इस्तेमाल, कोटे के उल्लंघन के बारे में बताने के लिए किया जाता है. उदाहरण के लिए, रोज़ का कोटा या पसंद के मुताबिक तय किया गया कोटा पूरा हो गया है.

फ़ील्ड
subject

string

वह विषय जिस पर कोटे की जांच नहीं हो सकी. उदाहरण के लिए, "clientip:" या "project:".
description

string

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

उदाहरण के लिए: "सेवा बंद है" या "पढ़ने के लिए रोज़ाना तय की गई सीमा पार हो गई है".
api_service

string

एपीआई सेवा, जिससे QuotaFailure.Violation शुरू होता है. कुछ मामलों में, कोटा से जुड़ी समस्याएं किसी ऐसी एपीआई सेवा से शुरू होती हैं जिसे कॉल नहीं किया गया था. दूसरे शब्दों में कहें, तो कॉल की गई एपीआई सेवा की निर्भरता, QuotaFailure की वजह हो सकती है. इस फ़ील्ड में, निर्भरता वाली एपीआई सेवा का नाम होगा.

उदाहरण के लिए, अगर कॉल किया गया एपीआई Kubernetes Engine API (container.googleapis.com) है और Kubernetes Engine API में ही कोटे का उल्लंघन होता है, तो इस फ़ील्ड की वैल्यू "container.googleapis.com" होगी. दूसरी ओर, अगर Compute Engine API (compute.googleapis.com) में Kubernetes Engine API के ज़रिए VM बनाते समय कोटे का उल्लंघन होता है, तो इस फ़ील्ड की वैल्यू "compute.googleapis.com" होगी.
quota_metric

string

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

उदाहरण के लिए, "compute.googleapis.com/cpus_per_vm_family", "storage.googleapis.com/internet_egress_bandwidth".
quota_id

string

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

उदाहरण के लिए, "CPUS-PER-VM-FAMILY-per-project-region".
quota_dimensions

map<string, string>

कोटे के उल्लंघन से जुड़े डाइमेंशन. हर नॉन-ग्लोबल कोटा, डाइमेंशन के सेट पर लागू होता है. कोटा मेट्रिक से यह तय होता है कि क्या गिना जाना चाहिए. वहीं, डाइमेंशन से यह तय होता है कि काउंटर को किन पहलुओं के लिए बढ़ाया जाना चाहिए.

उदाहरण के लिए, "हर वीएम फ़ैमिली के लिए, हर इलाके में सीपीयू" कोटा, "compute.googleapis.com/cpus_per_vm_family" मेट्रिक पर सीमा लागू करता है. यह सीमा, "region" और "vm_family" डाइमेंशन पर लागू होती है. अगर उल्लंघन "us-central1" क्षेत्र में और वीएम फ़ैमिली "n1" के लिए हुआ है, तो quota_dimensions ये होंगे,

{ "region": "us-central1", "vm_family": "n1", }

जब किसी कोटे को दुनिया भर में लागू किया जाता है, तो quota_dimensions हमेशा खाली रहेगा.
quota_value

int64

QuotaFailure के समय लागू किए गए कोटे की वैल्यू.

उदाहरण के लिए, अगर सीपीयू की संख्या पर लागू किए गए कोटे की वैल्यू "10" है, तो इस फ़ील्ड की वैल्यू में यह संख्या दिखेगी.QuotaFailure
future_quota_value

int64

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

उदाहरण के लिए, अगर उल्लंघन के समय सीपीयू के कोटे को 10 से 20 में बदलने के लिए रोलआउट किया जा रहा है, तो इस फ़ील्ड की वैल्यू 20 होगी.

RequestInfo

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

फ़ील्ड
request_id

string

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

string

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

ResourceInfo

ऐक्सेस किए जा रहे संसाधन के बारे में बताता है.

फ़ील्ड
resource_type

string

ऐक्सेस किए जा रहे संसाधन के टाइप का नाम. उदाहरण के लिए, "sql table", "cloud storage bucket", "file", "Google calendar". इसके अलावा, संसाधन का टाइप यूआरएल भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, "type.googleapis.com/google.pubsub.v1.Topic".
resource_name

string

ऐक्सेस किए जा रहे संसाधन का नाम. उदाहरण के लिए, शेयर किए गए कैलेंडर का नाम: "example.com_4fghdhgsrgh@group.calendar.google.com", अगर मौजूदा गड़बड़ी google.rpc.Code.PERMISSION_DENIED है.
owner

string

संसाधन का मालिक (ज़रूरी नहीं). उदाहरण के लिए, "user:" या "project:".
description

string

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

RetryInfo

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

हमेशा यह सुझाव दिया जाता है कि क्लाइंट को फिर से कोशिश करते समय, एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करना चाहिए.

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

फ़ील्ड
retry_delay

Duration

क्लाइंट को एक ही अनुरोध को फिर से करने से पहले, कम से कम इतने समय तक इंतज़ार करना चाहिए.

स्थिति

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

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

फ़ील्ड
code

int32

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

string

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

Any

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