פתרון בעיות

בדף הזה מוסבר איך לפתור בעיות שאתם עלולים להיתקל בהן במהלך השימוש ב-Workflows.

מידע נוסף זמין במאמרים בנושא מעקב וניפוי באגים ב-Workflows.

שגיאות פריסה

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

• הפניה למשתנה, לשלב או לתהליך עבודה משני שלא הוגדרו
• תחביר שגוי
  • כניסה שגויה
  • חסר או מיותר: {, }, ", - או :

לדוגמה, קוד המקור הבא מקפיץ הודעת שגיאה (throw) של פריסה כי פקודת חזרה מפנה למשתנה לא מוגדר, varC:

- step1:
    assign:
    - varA: "Hello"
    - varB: "World"
- step2:
    return: ${varC + varB}

קוד המקור השגוי הזה משמש בדוגמאות הבאות של Google Cloud מסוף ו-CLI של gcloud.

Could not deploy workflow: failed to build: error in step step2: error
evaluating return value: symbol 'varC' is neither a variable nor a
sub-workflow name (Code: 3)

ERROR: (gcloud.workflows.deploy) [INVALID_ARGUMENT] failed to build:
error in step step2: error evaluating return value: symbol 'varC' is neither
a variable nor a sub-workflow name

כדי לפתור את הבעיה, צריך לערוך את קוד המקור של תהליך העבודה. במקרה כזה, צריך לעיין במאמר בנושא varA במקום במאמר בנושא varC.

שגיאות בהרשאות של חשבון שירות ב-HTTP 403

הפעלת תהליך העבודה נכשלת כששרת HTTP מגיב עם קוד שגיאה 403. לדוגמה:

Permission 'iam.serviceaccounts.actAs' denied on service
account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

או

SERVICE_ACCOUNT does not have storage.objects.create access to the Google Cloud
Storage object. Permission 'storage.objects.create' denied on resource (or it may not exist).

כל תהליך עבודה משויך לחשבון שירות IAM בזמן יצירת תהליך העבודה. כדי לפתור את הבעיה, צריך להקצות לחשבון השירות תפקיד IAM אחד או יותר שמכילים את ההרשאות המינימליות שנדרשות לניהול תהליך העבודה. לדוגמה, אם רוצים לאפשר לתהליך העבודה לשלוח יומנים ל-Cloud Logging, צריך לוודא שחשבון השירות שמריץ את תהליך העבודה קיבל תפקיד שכולל את ההרשאה logging.logEntries.create. מידע נוסף זמין במאמר בנושא הענקת הרשאה לזרימת עבודה לגשת למשאבים ב- Google Cloud .

שגיאות HTTP 404 No such object או Not found

כשמשתמשים במחבר Cloud Storage, הביצוע של תהליך העבודה נכשל כששרת HTTP מגיב עם קוד שגיאה 404. לדוגמה:

HTTP server responded with error code 404
in step "read_input_file", routine "main", line: 13
{
  "body": "Not Found",
  "code": 404,
  ...
}

כדי שהנתיב יהיה בטוח, צריך להשתמש בקידוד URL לשמות של אובייקטים. אפשר להשתמש בפונקציות url_encode ו-url_encode_plus כדי לקודד תווים רלוונטיים כשהם מופיעים בשם האובייקט או במחרוזת השאילתה של כתובת URL של בקשה. לדוגמה:

- init:
    assign:
        - source_bucket: "my-bucket"
        - file_name: "my-folder/my-file.json"
- list_objects:
    call: googleapis.storage.v1.objects.get
    args:
        bucket: ${source_bucket}
        object: ${text.url_encode(file_name)}
        alt: media
    result: r
- returnStep:
    return: ${r}

אם לא תבצעו קידוד URL לשם האובייקט, ובקטגוריית האחסון שלכם יש תיקיות, הבקשה תיכשל. מידע נוסף זמין במאמרים קידוד של נתיב כתובת ה-URL ושיקולים למתן שמות ב-Cloud Storage.

שגיאות HTTP 429 Too many requests

יש מספר מקסימלי של הרצות פעילות של תהליכי עבודה שיכולות לפעול בו-זמנית. אם חורגים מהמכסה הזו, והתור להרצה מושבת או שהמכסה להרצה בתור מושגת, כל הרצה חדשה נכשלת ומתקבל קוד הסטטוס 429 Too many requests של HTTP.

התכונה 'הצטברות של ביצועים בתור' מאפשרת להוסיף ביצועים של תהליכי עבודה לתור אחרי שמגיעים למכסת הביצועים המקבילים. כברירת מחדל, התכונה 'הצטברות של בקשות לביצוע' מופעלת לכל הבקשות (כולל אלה שמופעלות על ידי Cloud Tasks), עם החריגים הבאים:

• כשיוצרים הפעלה באמצעות מחבר executions.run או executions.create בתהליך עבודה, השהיית ההפעלה מושבתת כברירת מחדל. כדי להגדיר את השדה הזה, צריך להגדיר במפורש את השדה disableConcurrencyQuotaOverflowBuffering של ההרצה לערך false.
• במקרים של הפעלות שמופעלות על ידי Pub/Sub, התכונה 'הצטברות של בקשות להפעלה' מושבתת ואי אפשר להגדיר אותה.

מידע נוסף מופיע במאמר בנושא ניהול של הצטברות בקשות לביצוע.

אפשר גם להפעיל תור של Cloud Tasks כדי להריץ תהליכי עבודה משניים בקצב שאתם מגדירים, וכך להשיג קצב הרצה טוב יותר. במקרה כזה, כדאי להשבית במפורש את הגיבוי של ההרצה.

שגיאות בהרשאות של חשבון שירות בין פרויקטים

אם אתם מקבלים שגיאה PERMISSION_DENIED כשאתם מנסים להשתמש בחשבון שירות בין פרויקטים כדי לפרוס תהליך עבודה, אתם צריכים לוודא שהאילוץ הבוליאני iam.disableCrossProjectServiceAccountUsage לא נאכף בפרויקט ושהגדרתם את חשבון השירות בצורה נכונה. למידע נוסף, ראו פריסת תהליך עבודה עם חשבון שירות חוצה-פרויקטים.

שם המשאב צריך להיות בהתאם ל-RFC 1123

הפעלת תהליך העבודה נכשלת כששרת HTTP מגיב עם קוד שגיאה 400. לדוגמה:

"description": "must conform to RFC 1123: only lowercase, digits, hyphens,
and periods are allowed, must begin and end with letter or digit, and less
than 64 characters."

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

לדוגמה, אי אפשר להקצות משתנה באופן הבא: - string: hello-${world}. במקום זאת, צריך לבצע את הפעולות האלה:

  - assign_vars:
      assign:
          - string: "hello"
          - string: ${string+" "+"world"}

  [
    {
      "assign_vars": {
        "assign": [
          {
            "string": "hello"
          },
          {
            "string": "${string+" "+"world"}"
          },
        ]
      }
    }
  ]

ביטויים שמכילים נקודתיים

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

אם יוצרים תהליך עבודה באמצעות מסוף Google Cloud , אי אפשר להציג את תהליך העבודה באופן חזותי במסוף Google Cloud , ויכול להיות שתופיע אזהרה שדומה לזו:

כדי לפתור את הבעיה הזו, צריך להוסיף מירכאות יחידות סביב ביטוי ה-YAML:

מומלץ: '${"a: " +string(a)}'

לא מומלץ: ${"a: " +string(a)}

מיפוי מקשים באמצעות תווים שאינם אלפאנומריים

כשניגשים למפתחות עם תווים לא אלפאנומריים (לדוגמה, סימן הקריאה ב-"special!key": value), צריך להוסיף מרכאות לשם המפתח. אם שם המפתח לא מוקף במירכאות, אי אפשר לפרוס את תהליך העבודה. לדוגמה, אם מנסים לפרוס את קוד המקור הבא, מתקבלת השגיאה token recognition error:

- init:
    assign: