בעיות ידועות בתהליכי עבודה

התנהגויות לא צפויות, מגבלות תפעוליות ופתרונות זמניים זמינים יכולים להשפיע על ההרצות של Workflows והמחברים. אפשר גם לבדוק אם יש בעיות קיימות או לפתוח בעיות חדשות באתרי המעקב הציבוריים אחרי בעיות.

הצבת for ישירות אחרי try

הצבת התג for ישירות אחרי התג try גורמת לשגיאה. לדוגמה, אפשר להציב שלב יחיד ישירות אחרי try, כך:

- try:
    try:
      call: sys.log
      args:
        data: works
    retry: ${http.default_retry}

עם זאת, אם מציבים את for אחרי try, השלב נכשל ואי אפשר לפרוס את תהליך העבודה. לדוגמה:

- try:
    try:
      for:
        value: v
        range: [1,2]
        steps:
          - log:
              call: sys.log
              args:
                data: ${v}
    retry: ${http.default_retry}

הודעת השגיאה היא:

Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)

הפתרון העקיף הוא להוסיף שלב עם שם אחרי try. לדוגמה:

- try:
    try:
      steps:
        - loopStep:
            for:
              value: v
              range: [1,2]
              steps:
                - log:
                    call: sys.log
                    args:
                      data: ${v}
    retry: ${http.default_retry}

אירועים שגדולים יותר מהגודל המקסימלי של הארגומנטים

אם משתמשים ב-Workflows כיעד לטריגר של Eventarc, אירועים שגדולים מהגודל המקסימלי של הארגומנטים של Workflows לא יפעילו את הביצוע של תהליך העבודה. מידע נוסף זמין במאמר מכסות ומגבלות.

HTTP request lost הודעה ביומנים

כשמריצים תהליך עבודה שקורא ל-Cloud Build, התהליך נכשל ומופיעה הודעה HTTP request lost ביומנים שדומה להודעה הבאה:

[1500] HTTP request lost
INTERNAL MESSAGE: HTTP request lost
...
CAUSED BY:
RPC::UNREACHABLE: RPC connection timed out: FDD 20s, last read 2022-10-14 16:39:04 -0700 PDT

אם נתקלים בשגיאה הזו, אפשר לנסות לשנות את תהליך העבודה באמצעות הטמעה של מדיניות ניסיון חוזר או באמצעות טיפול חריג מפורש.

רישום שיחות ביומן ושיטת accessString לאחזור נתונים סודיים

אם call logging level מוגדר ל-log-all-calls כשמשתמשים בשיטת העזר accessString כדי לאחזר נתונים סודיים, הערך הסודי לא מצונזר ומודפס בטקסט פשוט ביומנים ב-jsonPayload.succeeded.response.

חריגה של פעולה ארוכת טווח כשמשתמשים במחבר Cloud Resource Manager

השיטה של המחבר Resource Manager‏, googleapis.cloudresourcemanager.v3.projects.patch, לא מחזירה שם של פעולה ממושכת (LRO). גם אם הבקשה מצליחה, יכול להיות שתוצג חריגה שדומה לזו:

exception: "{"message":"Long-running operation returned unexpected response.",
"operation":{"done":true,"response":{"@type":"type.googleapis.com/google.cloud.resourcemanager.v3.Project",
...
"tags":["ResponseTypeError"]}"

כדי למנוע שגיאה בבדיקת סטטוס של פעולה ארוכת טווח, צריך להגדיר את פרמטר המחבר skip_polling לערך true, כך שהקריאה להפעלת המחבר לא תחסום את התהליך אם הבקשה הראשונית תצליח. בקשה מוצלחת מחזירה "done":true. אחרת, כדי לזהות חריגים, צריך להשתמש במבנה try/except. מידע נוסף זמין במאמר הפניה למחברים.

בקשות HTTP אל Google Kubernetes Engine ‏ (GKE)

לכל אשכול GKE יש מישור בקרה שמטפל בבקשות של Kubernetes API. למישור הבקרה יש שני סוגים של נקודות קצה (endpoints) לגישה לאשכול: נקודות קצה מבוססות DNS ונקודות קצה מבוססות IP. מידע נוסף זמין במאמר בנושא גישה למישור הבקרה.

‫Workflows לא תומך יותר בבקשות HTTP לנקודות קצה שמבוססות על כתובות IP של מישורי בקרה של אשכולות GKE. מידע נוסף על ההיקף וההשפעה של הפסקת התמיכה זמין בהודעה בנוגע לשירות.

כדי לוודא שהתהליך העסקי פועל כמו שצריך, צריך לגשת אל נקודות קצה מבוססות DNS. כדי לגשת לנקודות קצה שמבוססות על DNS, מומלץ להשתמש במחבר Kubernetes API בתהליך עבודה. מידע נוסף זמין במאמר בנושא גישה לאובייקטים של Kubernetes API באמצעות מחבר.

המאמרים הבאים

טיפים לפתרון בעיות