gRPC रिस्पॉन्स में ये स्टेटस कोड दिखाए जा सकते हैं. यह बात, इस साइट पर दर्ज किए गए gRPC के सभी वर्शन पर लागू होती है.
| कोड | स्थिति | ज़रूरी जानकारी |
|---|---|---|
| 0 | OK |
Success को वापसी करें |
| 1 | CANCELLED |
कार्रवाई को आम तौर पर कॉलर ने रद्द कर दिया था. |
| 2 | UNKNOWN |
उदाहरण के लिए, यह गड़बड़ी तब दिख सकती है, जब किसी दूसरे ऐड्रेस स्पेस से मिला स्टेटस का मान किसी ऐसे गड़बड़ी-स्पेस से हो जिसे इस पता स्पेस में नहीं जाना जाता. इसके अलावा, ऐसे एपीआई जो गड़बड़ी की ज़्यादा जानकारी नहीं दिखाते हैं उनकी गड़बड़ियां भी इस गड़बड़ी में बदली जा सकती हैं. |
| 3 | INVALID_ARGUMENT |
क्लाइंट ने एक अमान्य तर्क बताया. |
| 4 | DEADLINE_EXCEEDED |
कार्रवाई पूरी होने से पहले ही समयसीमा खत्म हो गई थी. सिस्टम की स्थिति बदलने वाली कार्रवाई के लिए, यह गड़बड़ी दिख सकती है, भले ही कार्रवाई पूरी हो गई हो. उदाहरण के लिए, किसी सर्वर से मिलने वाला रिस्पॉन्स, जिसकी समयसीमा खत्म होने में काफ़ी देरी हुई. |
| 5 | NOT_FOUND |
अनुरोध की गई कुछ इकाई नहीं मिली. |
| 6 | ALREADY_EXISTS |
क्लाइंट ने जो इकाई बनाने की कोशिश की है वह पहले से मौजूद है. |
| 7 | PERMISSION_DENIED |
कॉल करने वाले के पास यह कार्रवाई करने की अनुमति नहीं है. कुछ संसाधन खत्म होने की वजह से ऐप्लिकेशन को अस्वीकार किए जाने के लिए PERMISSION_DENIED का इस्तेमाल न करें. इन गड़बड़ियों के लिए RESOURCE_EXHAUSTED का इस्तेमाल करें. अगर कॉलर की पहचान नहीं हो पाती है, तो PERMISSION_DENIED का इस्तेमाल न करें. इन गड़बड़ियों के लिए, UNAUTHENTICATED का इस्तेमाल करें. PERMISSION_DENIED का गड़बड़ी कोड पाने का मतलब यह नहीं है कि अनुरोध मान्य है या अनुरोध की गई इकाई मौजूद है या पहले से तय की गई अन्य शर्तों को पूरा करती है. |
| 8 | RESOURCE_EXHAUSTED |
कुछ संसाधन खत्म हो गए हैं, शायद हर उपयोगकर्ता के लिए कोटा खत्म हो गया है या शायद पूरे फ़ाइल सिस्टम में जगह नहीं है. |
| 9 | FAILED_PRECONDITION |
कार्रवाई अस्वीकार कर दी गई थी, क्योंकि सिस्टम, कार्रवाई को पूरा करने के लिए ज़रूरी स्थिति में नहीं है. उदाहरण के लिए, मिटाई जाने वाली डायरेक्ट्री खाली नहीं है या किसी गैर-डायरेक्ट्री पर rmder कार्रवाई लागू की जाती है. |
| 10 | ABORTED |
आम तौर पर, सीक्वेंसर जांच में गड़बड़ी या लेन-देन रद्द होने जैसी एक ही मुद्रा से जुड़ी समस्या की वजह से, कार्रवाई को रद्द कर दिया गया. |
| 11 | OUT_OF_RANGE |
कार्रवाई की कोशिश मान्य सीमा से पहले की गई थी. |
| 12 | UNIMPLEMENTED |
यह कार्रवाई लागू नहीं की गई है या इस सेवा में काम नहीं करती/चालू नहीं करती. |
| 13 | INTERNAL |
अंदरूनी गड़बड़ियां. इसका मतलब है कि सिस्टम में काम करने वाले कुछ ऐसे वैरिएंट काम नहीं कर रहे जिनकी उम्मीद थी. गड़बड़ी का यह कोड, गंभीर गड़बड़ियों के लिए रिज़र्व है. |
| 14 | UNAVAILABLE |
फ़िलहाल, सेवा उपलब्ध नहीं है. यह समस्या कुछ समय के लिए होती है. अगर बैकऑफ़ के साथ फिर से कोशिश की जाए, तो इसे ठीक किया जा सकता है. |
| 15 | DATA_LOSS |
डेटा को वापस नहीं पाया जा सकता या खराब हो गया है. |
| 16 | UNAUTHENTICATED |
कार्रवाई के लिए अनुरोध में पुष्टि करने के मान्य क्रेडेंशियल नहीं हैं. |
कभी-कभी कई गड़बड़ी कोड लागू हो सकते हैं. सेवाओं को लागू होने वाला
सबसे खास गड़बड़ी कोड लौटाना चाहिए. उदाहरण के लिए, अगर दोनों कोड लागू होते हैं, तो FAILED_PRECONDITION की जगह OUT_OF_RANGE को प्राथमिकता दें.
इसी तरह, FAILED_PRECONDITION के बजाय NOT_FOUND या ALREADY_EXISTS को प्राथमिकता दें.
FAILED_PRERATE बनाम निरस्त बनाम UNavailable
यहां एक लिटमस टेस्ट दिया गया है, जिससे आपको FAILED_PRECONDITION, ABORTED, और UNAVAILABLE में से किसी एक को तय करने में मदद मिल सकती है:
- अगर क्लाइंट उन कॉल को फिर से कोशिश कर सकता है जो काम नहीं कर रहे हैं, तो
UNAVAILABLEका इस्तेमाल करें. - अगर क्लाइंट को हाई-लेवल पर फिर से कोशिश करनी चाहिए, तो
ABORTEDका इस्तेमाल करें. उदाहरण के लिए, जब क्लाइंट की ओर से तय की गई जांच और सेट काम नहीं करता. इससे पता चलता है कि क्लाइंट को पढ़ने-बदलने-लिखने के क्रम को फिर से शुरू करना चाहिए. - अगर क्लाइंट को फिर से सिस्टम की स्थिति ठीक किए जाने तक फिर से कोशिश नहीं करनी चाहिए, तो
FAILED_PRECONDITIONका इस्तेमाल करें. उदाहरण के लिए, अगर डायरेक्ट्री में खाली जगह न होने की वजह से कोई "rmder" से काम नहीं कर रहा है, तोFAILED_PRECONDITIONको लौटाना सबसे अच्छा है. ऐसा इसलिए, क्योंकि क्लाइंट को फिर से तब तक कोशिश नहीं करनी चाहिए, जब तक डायरेक्ट्री से फ़ाइलें न मिटा दी जाएं.
INVALID_LABEL बनाम FAILED_PRERATE बनाम OUT_OF_RANGE
यहां एक लिटमस टेस्ट दिया गया है, जिससे आपको INVALID_ARGUMENT, FAILED_PRECONDITION, और OUT_OF_RANGE में से किसी एक को तय करने में मदद मिल सकती है:
- अगर सिस्टम की स्थिति चाहे जो भी हो, अगर तर्क समस्या पैदा करते हैं, तो
INVALID_ARGUMENTका इस्तेमाल करें. उदाहरण के लिए: गलत यूआरएल - अगर सिस्टम की स्थिति की वजह से कोई वैल्यू सीमा से बाहर है, तो
OUT_OF_RANGEका इस्तेमाल करें. उदाहरण के लिए, start_datestart_date_restrictसे पहले की है. - अगर सिस्टम की स्थिति की वजह से वैल्यू अमान्य है, लेकिन
OUT_OF_RANGEवैल्यू नहीं है, तोFAILED_PRECONDITIONका इस्तेमाल करें.