אפשר להחזיר את קודי המצב הבאים בתשובות gRPC. הכלל הזה רלוונטי לכל הגרסאות של gRPC שמתועדות באתר הזה.
| קוד | סטטוס | הערות |
|---|---|---|
| 0 | OK |
חזרה ב-Success |
| 1 | CANCELLED |
הפעולה בוטלה, בדרך כלל על ידי המתקשר. |
| 2 | UNKNOWN |
לדוגמה, ייתכן שהשגיאה הזו תוחזר כאשר ערך 'סטטוס' שהתקבל ממרחב כתובות אחר שייך למרחב שגיאות שאינו ידוע במרחב הכתובות הזה. כמו כן, ניתן להמיר לשגיאה הזו שגיאות שנוצרו על ידי ממשקי API שלא מחזירים מספיק מידע על שגיאות. |
| 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 |
השירות הזה לא זמין כרגע. סביר להניח שזה מצב חולף שניתן לתקן אם מנסים שוב עם השהיה (backoff). |
| 15 | DATA_LOSS |
פגיעה בנתונים או אובדן נתונים שלא ניתן לשחזר. |
| 16 | UNAUTHENTICATED |
לבקשה אין פרטי כניסה חוקיים לאימות עבור הפעולה. |
לפעמים יכולים לחול כמה קודי שגיאה. השירותים אמורים להחזיר את קוד השגיאה הספציפי ביותר. לדוגמה, עדיף להשתמש ב-OUT_OF_RANGE על פני FAILED_PRECONDITION אם שני הקודים מתאימים.
באופן דומה, עדיף NOT_FOUND או ALREADY_EXISTS על פני FAILED_PRECONDITION.
FAILED_PRECONDITION לעומת ABORTED לעומת UNAVAILABLE
המבחן הוא מבחן תאורה שיכול לעזור לכם להחליט בין FAILED_PRECONDITION, ABORTED ו-UNAVAILABLE:
- יש להשתמש ב-
UNAVAILABLEאם הלקוח יכול לנסות שוב רק את הקריאה שנכשלה. - כדאי להשתמש ב-
ABORTEDאם הלקוח צריך לנסות שוב ברמה גבוהה יותר, למשל כשבדיקה והגדרה שמצוינת על ידי הלקוח נכשלת, וכתוצאה מכך הלקוח צריך להפעיל מחדש רצף של קריאה-שינוי-כתיבה. - משתמשים ב-
FAILED_PRECONDITIONאם הלקוח לא אמור לנסות שוב עד שמצב המערכת יתוקן באופן מפורש. לדוגמה, אם פונקציית "rmdir" נכשלת כי הספרייה לא ריקה, עדיף להחזיר את הערךFAILED_PRECONDITIONכי הלקוח לא צריך לנסות שוב אלא אם הקבצים נמחקים מהספרייה.
INVALID_IAB לעומת FAILED_PRECONDITION לעומת OUT_OF_RANGE
המבחן הוא מבחן תאורה שיכול לעזור לכם להחליט בין INVALID_ARGUMENT, FAILED_PRECONDITION ו-OUT_OF_RANGE:
- אם הארגומנטים בעייתיים, ללא קשר למצב המערכת, משתמשים בפונקציה
INVALID_ARGUMENT. לדוגמה: כתובת URL לא תקינה - אם ערך מסוים נמצא מחוץ לטווח בגלל מצב המערכת, אפשר להשתמש בפונקציה
OUT_OF_RANGE. לדוגמה, start_date חל לפניstart_date_restrict. - אפשר להשתמש ב-
FAILED_PRECONDITIONאם הערך לא תקין בגלל מצב המערכת, אבל הוא לא ערך שלOUT_OF_RANGE.