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