Package google.rpc

इंडेक्स

कोड

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

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

Enums
OK

कोई गड़बड़ी नहीं है; सफलता मिलने पर वापस मिले.

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

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

एचटीटीपी मैपिंग: 499 क्लाइंट का अनुरोध
UNKNOWN

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

एचटीटीपी मैपिंग: 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 मंज़ूरी नहीं है
RESOURCE_EXHAUSTED

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

एचटीटीपी मैपिंग: 429 बहुत ज़्यादा अनुरोध
FAILED_PRECONDITION

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

सेवा लागू करने वाले लोग, FAILED_PRECONDITION, ABORTED, और UNAVAILABLE के बीच फ़ैसला लेने के लिए इन दिशा-निर्देशों का पालन कर सकते हैं: (a) अगर क्लाइंट असफल कॉल होने पर भी फिर से कोशिश कर सकता है, तो UNAVAILABLE का इस्तेमाल करें. (b) अगर क्लाइंट को बड़े लेवल पर फिर से कोशिश करनी चाहिए, तो ABORTED का इस्तेमाल करें. उदाहरण के लिए, जब क्लाइंट की ओर से तय किया गया टेस्ट और सेट काम नहीं करता, तो इसका मतलब है कि क्लाइंट को पढ़ने-में बदलाव करने का क्रम फिर से शुरू करना चाहिए. (c) अगर सिस्टम की स्थिति साफ़ तौर पर ठीक नहीं हो जाती, तो क्लाइंट को फिर से कोशिश नहीं करनी चाहिए. ऐसे में, FAILED_PRECONDITION का इस्तेमाल करें. उदाहरण के लिए, अगर एक "rmder" यह प्रोसेस पूरी नहीं हो पाती, क्योंकि डायरेक्ट्री खाली नहीं है. 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

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

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

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

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

HTTP मैपिंग: 503 सेवा अनुपलब्ध
DATA_LOSS

डेटा खो जाना या खराब हो जाना.

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

स्थिति

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

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

फ़ील्ड
code

int32

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

string

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

Any

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