אם נתקלתם בבעיות, אתם יכולים להיעזר בקטעים הבאים.
מצב אובדן ב-Fleet Engine
כשעובדים עם Fleet Engine, חשוב לתכנן את ההטמעה כך שתהיה עמידה בפני כשלים. לדוגמה, אם שולחים בקשה ל-Fleet Engine לעדכן רכב, יכול להיות שתתקבל שגיאה שמציינת שהרכב לא קיים. לאחר מכן, ההטמעה שלכם צריכה ליצור מחדש את הרכב במצב החדש.
במקרה הנדיר מאוד של כשל קטסטרופלי ב-Fleet Engine, יכול להיות שתצטרכו ליצור מחדש את רוב או את כל כלי הרכב והמשימות. אם קצב היצירה גבוה מדי, יכול להיות שחלק מהבקשות ייכשלו שוב בגלל בעיות במכסות, כי בדיקות המכסות נועדו למנוע התקפות מניעת שירות (DoS). במקרה כזה, צריך להאט את קצב היצירה מחדש באמצעות אסטרטגיית השהיה לפני ניסיון חוזר (backoff).
ניסיונות חוזרים
חשוב לוודא שהמערכת שלכם מבצעת ניסיונות חוזרים של בקשות ל-Fleet Engine, כי לפעמים הן עלולות להיכשל. ספריות הלקוח של Fleet Engine מנסות שוב כברירת מחדל.
מצב אבוד באפליקציית הנהג
אם אפליקציית הנהג קורסת, היא צריכה ליצור מחדש את המצב הנוכחי ב-Driver SDK. האפליקציה צריכה לנסות ליצור מחדש את המשימות כדי לוודא שהן קיימות ולשחזר את המצבים הנוכחיים שלהן. האפליקציה צריכה גם ליצור מחדש ולהגדיר באופן מפורש את רשימת התחנות של Driver SDK.
הערה: השחזורים האלה צריכים להתבצע באופן אוטונומי בלי להסתמך על מידע מ-Fleet Engine, מלבד שגיאות שמציינות אם ישות כבר קיימת במסד הנתונים ומתי. אם הישות כבר קיימת, אפשר להתעלם מהשגיאה ולעדכן את הישות באמצעות המזהה שלה.
שגיאות שקשורות לחריגה מהזמן הקצוב
אם מופיעה השגיאה DEADLINE_EXCEEDED כששולחים קריאה ל-Fleet Engine, סימן שהבקשה נמשכה יותר מהזמן הקצוב שהוגדר. לספריות הלקוח של Fleet Engine יש ערכי ברירת מחדל של זמן קצוב לתפוגה, אבל יכול להיות שתצטרכו לשנות אותם.
למידע כללי על מועדים אחרונים ב-gRPC, קראו את המאמר gRPC ומועדים אחרונים.
כדי להגדיר את המועד האחרון כשמשתמשים בספריית הלקוח של Fleet Engine ב-Java, אפשר לשנות את הגדרות הניסיון החוזר של ה-RPC. בדוגמה הבאה אפשר לראות איך מגדירים זמן קצוב לתפוגה בהתאמה אישית כשמגדירים את VehicleService:
VehicleServiceSettings.Builder settingsBuilder = VehicleServiceSettings.newBuilder();
// Set the timeout to 10 seconds.
settingsBuilder
.getVehicleSettings()
.setRetrySettings(
settingsBuilder.getVehicleSettings().getRetrySettings().toBuilder()
.setTotalTimeout(java.time.Duration.ofSeconds(10))
.build());
VehicleServiceClient client = VehicleServiceClient.create(settingsBuilder.build());
שגיאות API נפוצות
בקטע הזה מפורטות שגיאות נפוצות ב-API, הסיבות להן ואיך לפתור אותן.
NOT_FOUND (HTTP 404)
הישות המבוקשת (כמו רכב, נסיעה או משימה) לא נמצאה.
- הסיבה: בדרך כלל השגיאה הזו נגרמת כשמנסים לאחזר, לעדכן או למחוק ישות באמצעות מזהה שלא קיים במסד הנתונים.
- פתרון: לפני שמנסים לגשת לישות, צריך לוודא שמזהה הישות נכון ושהישות נוצרה בהצלחה.
ALREADY_EXISTS (HTTP 409)
הישות שניסית ליצור כבר קיימת.
- הסיבה: קריאה ל-method ליצירה (כמו
CreateVehicleאוCreateTrip) עם מזהה שכבר נמצא בשימוש. - תיקון: מעדכנים את הישות הקיימת או משתמשים במזהה ייחודי חדש בבקשת היצירה.
PERMISSION_DENIED (HTTP 403)
אין לך את ההרשאות הנדרשות כדי להשלים את הבקשה.
- הסיבה: בדרך כלל זה קורה אם ב-JSON Web Token (JWT) חסרות ההצהרות הנכונות, או אם בחשבון השירות שחותם על ה-JWT חסרים תפקידי ה-IAM הנדרשים. לדוגמה, "JWT does not contain a matching scope for requested trip".
- תיקון: בודקים את ההרשאות של חשבון השירות ומוודאים שההצהרות של JWT כוללות את ההיקפים הנכונים של הישות שאליה מנסים לגשת.
INVALID_ARGUMENT (HTTP 400)
אחד או יותר מהארגומנטים שהועברו בבקשה לא תקינים.
- הסיבה: יכולות להיות לכך כמה סיבות, כמו ציון ערך מחוץ לטווח (למשל, קיבולת מקסימלית), שדה חובה חסר (למשל,
VehicleType) או ציון קואורדינטות לא חוקיות של נקודת איסוף. - תיקון: בודקים את הודעת השגיאה לגבי השדה הספציפי שלא תקין ומוודאים שהבקשה תואמת למפרט ה-API.
FAILED_PRECONDITION (HTTP 400)
הפעולה נדחתה כי המערכת לא במצב שנדרש כדי לבצע אותה.
- הסיבה: הסיבות הנפוצות כוללות ניסיון לשנות נסיעה במצב
COMPLETEאוCANCELEDלמצב אחר, או ניסיון להקצות משימה במצבCLOSEDלרכב. - תיקון: ודאו שהמצב הנוכחי של הישות מאפשר את הפעולה שאתם מנסים לבצע. כדי לדעת מהן ההפרות הספציפיות, אפשר לקרוא את הודעת השגיאה.
UNAVAILABLE (HTTP 503)
השירות לא זמין.
- הסיבה: הבעיה הזו מצביעה על בעיה זמנית בשירות Fleet Engine.
- תיקון: אפשר לנסות שוב את הבקשה בבטחה עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).