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

בדף הזה מפורטות בעיות מוכרות ב-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

אם רמת רישום השיחות מוגדרת ל-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. מידע נוסף זמין במאמר Connectors reference.

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

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

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

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

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

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