פתרון בעיות: תהליכי עבודה

"Workflow not found or not accessible"

תהליך העבודה קיים אך שמור ברמת סיווג גבוהה יותר מרמת ה-taint הנוכחית של הסשן שלך.

תהליכי עבודה שנשמרו במהלך סשן CONFIDENTIAL אינם נראים לסשנים ברמת PUBLIC או INTERNAL. המאגר משתמש בבדיקות canFlowTo בכל טעינה, ומחזיר null (מוצג כ-"not found") כאשר סיווג תהליך העבודה חורג מ-taint הסשן.

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

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

---

"Workflow classification ceiling breached"

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

לדוגמה, תהליך עבודה עם classification_ceiling: INTERNAL ייעצר אם קריאת triggerfish:memory שולפת נתוני CONFIDENTIAL שמסלימים את taint הסשן.

פתרון:

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

---

שגיאות ניתוח YAML

"YAML parse error: ..."

טעויות תחביר YAML נפוצות:

הזחה. YAML רגיש לרווחים. השתמש ברווחים, לא בטאבים. כל רמת קינון צריכה להיות בדיוק 2 רווחים.

# שגוי — טאבים או הזחה לא עקבית
do:
- fetch:
      call: http

# נכון
do:
  - fetch:
      call: http

חוסר מרכאות סביב ביטויים. מחרוזות ביטוי עם ${ } חייבות להיות במרכאות, אחרת YAML מפרש { כמיפוי מוטבע.

# שגוי — שגיאת ניתוח YAML
endpoint: ${ .config.url }

# נכון
endpoint: "${ .config.url }"

חוסר בלוק document. כל תהליך עבודה חייב לכלול שדה document עם dsl, namespace ו-name:

document:
  dsl: "1.0"
  namespace: my-workflows
  name: my-workflow

"Workflow YAML must be an object"

ה-YAML נותח בהצלחה אך התוצאה היא סקלר או מערך, לא אובייקט. בדוק של-YAML שלך יש מפתחות ברמה עליונה (document, do).

"Task has no recognized type"

כל רשומת משימה חייבת לכלול בדיוק מפתח סוג אחד: call, run, set, switch, for, raise, emit או wait. אם המנתח לא מוצא אף אחד ממפתחות אלה, הוא מדווח על סוג לא מזוהה.

סיבה נפוצה: שגיאת כתיב בשם סוג המשימה (למשל, calls במקום call).

---

כשלי הערכת ביטויים

ערכים שגויים או ריקים

ביטויים משתמשים בתחביר ${ .path.to.value }. הנקודה המובילה נדרשת -- היא מעגנת את הנתיב בשורש הקשר הנתונים של תהליך העבודה.

# שגוי — חוסר נקודה מובילה
value: "${ result.name }"

# נכון
value: "${ .result.name }"

"undefined" בפלט

ה-dot-path לא התפרש לכלום. סיבות נפוצות:

• שם משימה שגוי. כל משימה שומרת את תוצאתה תחת שמה. אם המשימה שלך נקראת fetch_data, הפנה לתוצאתה כ-${ .fetch_data }, לא ${ .data } או ${ .result }.
• קינון שגוי. אם הקריאה HTTP מחזירה {"data": {"items": [...]}}, הפריטים נמצאים ב-${ .fetch_data.data.items }.
• הוספת אינדקס למערך. השתמש בתחביר סוגריים: ${ .items[0].name }. נתיבי נקודה בלבד אינם תומכים באינדקסים מספריים.

תנאים בוליאניים לא עובדים

השוואות ביטויים הן מחמירות (===). ודא שהסוגים תואמים:

# זה ייכשל אם .count הוא מחרוזת "0"
if: "${ .count == 0 }"

# עובד כש-.count הוא מספר
if: "${ .count == 0 }"

בדוק אם משימות upstream מחזירות מחרוזות או מספרים. תגובות HTTP לעיתים קרובות מחזירות ערכי מחרוזת שלא צריכים המרה להשוואה -- פשוט השווה מול צורת המחרוזת.

---

כשלי קריאות HTTP

Timeouts

קריאות HTTP עוברות דרך כלי web_fetch. אם שרת היעד איטי, הבקשה עלולה לפוג. אין עקיפת timeout למשימה בודדת עבור קריאות HTTP ב-workflow DSL -- ה-timeout ברירת המחדל של כלי web_fetch חל.

חסימות SSRF

כל HTTP יוצא ב-Triggerfish מפרש DNS תחילה ובודק את ה-IP המפורש מול רשימת חסימה מקודדת. טווחי IP פרטיים ושמורים חסומים תמיד.

אם תהליך העבודה שלך קורא לשירות פנימי בכתובת IP פרטית (למשל, http://192.168.1.100/api), הוא ייחסם על ידי מניעת SSRF. זה בכוונה ולא ניתן להגדרה.

פתרון: השתמש בשם מארח ציבורי שמתפרש ל-IP ציבורי, או השתמש ב- triggerfish:mcp כדי לנתב דרך שרת MCP שיש לו גישה ישירה.

כותרות חסרות

סוג הקריאה http ממפה את with.headers ישירות לכותרות הבקשה. אם ה-API שלך דורש אימות, כלול את הכותרת:

- fetch:
    call: http
    with:
      endpoint: "https://api.example.com/data"
      headers:
        Authorization: "Bearer ${ .api_token }"

ודא שערך הטוקן מסופק בקלט תהליך העבודה או מוגדר על ידי משימה קודמת.

---

מגבלת רקורסיה של תת-תהליכי עבודה

"Workflow recursion depth exceeded maximum of 5"

תת-תהליכי עבודה יכולים להיות מקוננים עד 5 רמות עומק. מגבלה זו מונעת רקורסיה אינסופית כאשר תהליך עבודה A קורא לתהליך עבודה B שקורא לתהליך עבודה A.

פתרון:

• שטח את שרשרת תהליכי העבודה. שלב שלבים לפחות תהליכי עבודה.
• בדוק הפניות מעגליות שבהן שני תהליכי עבודה קוראים זה לזה.

---

הרצת Shell מושבתת

"Shell execution failed" או תוצאה ריקה ממשימות run

דגל allowShellExecution בהקשר כלי תהליך העבודה שולט האם משימות run עם יעדי shell או script מותרות. כאשר מושבת, משימות אלה נכשלות.

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

---

תהליך העבודה רץ אך מייצר פלט שגוי

ניפוי באגים עם workflow_history

השתמש ב-workflow_history כדי לבדוק הרצות קודמות:

workflow_history with workflow_name: "my-workflow" and limit: "5"

כל רשומת היסטוריה כוללת:

• status -- completed או failed
• error -- הודעת שגיאה אם נכשל
• taskCount -- מספר המשימות בתהליך העבודה
• startedAt / completedAt -- מידע תזמון

בדיקת זרימת הקשר

כל משימה שומרת את תוצאתה בהקשר הנתונים תחת שם המשימה. אם לתהליך העבודה שלך יש משימות בשם fetch, transform ו-save, הקשר הנתונים לאחר שלוש המשימות נראה כך:

{
  "fetch": { "...http response..." },
  "transform": { "...transformed data..." },
  "save": { "...save result..." }
}

טעויות נפוצות:

• דריסת הקשר. משימת set שמקצה למפתח שכבר קיים תחליף את הערך הקודם.
• הפניה למשימה שגויה. הפניה ל-${ .step1 } כשהמשימה נקראת step_1.
• טרנספורמציית קלט שמחליפה הקשר. הנחיית input.from מחליפה את הקשר הקלט של המשימה כולו. אם אתה משתמש ב-input.from: "${ .config }", המשימה רואה רק את אובייקט ה-config, לא את ההקשר המלא.

פלט חסר

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

---

"Permission denied" ב-workflow_delete

כלי workflow_delete טוען את תהליך העבודה תחילה באמצעות רמת ה-taint הנוכחית של הסשן. אם תהליך העבודה נשמר ברמת סיווג שחורגת מ-taint הסשן שלך, הטעינה מחזירה null ו-workflow_delete מדווח "not found" במקום "permission denied."

זה מכוון -- קיומם של תהליכי עבודה מסווגים אינו נחשף לסשנים בסיווג נמוך יותר.

פתרון: הסלם את taint הסשן שלך כך שיתאים או יעלה על רמת הסיווג של תהליך העבודה לפני מחיקתו. או מחק אותו מאותו סוג סשן שבו נשמר במקור.

---

ריפוי עצמי

"Step metadata missing on task 'X': self-healing requires description, expects, produces"

כאשר self_healing.enabled הוא true, כל משימה חייבת לכלול את כל שלושת שדות המטא-נתונים. המנתח דוחה את תהליך העבודה בזמן השמירה אם חסר כל אחד מהם.

פתרון: הוסף description, expects ו-produces לבלוק metadata של כל משימה:

- my-task:
    call: http
    with:
      endpoint: "https://example.com/api"
    metadata:
      description: "What this step does and why"
      expects: "What this step needs as input"
      produces: "What this step outputs"

---

"Self-healing config mutation rejected in version proposal"

סוכן הריפוי הציע גרסה חדשה של תהליך העבודה שמשנה את בלוק התצורה של self_healing. זה אסור -- הסוכן אינו יכול לשנות את תצורת הריפוי שלו עצמו.

זה עובד כמתוכנן. רק בני אדם יכולים לשנות את תצורת self_healing על ידי שמירת גרסה חדשה של תהליך העבודה ישירות דרך workflow_save.

---

סוכן הריפוי לא נוצר

תהליך העבודה רץ אך סוכן ריפוי לא מופיע. בדוק:

1. enabled הוא true ב-metadata.triggerfish.self_healing.
2. התצורה במיקום הנכון -- חייבת להיות מקוננת תחת metadata.triggerfish.self_healing, לא ברמה העליונה.
3. לכל השלבים יש מטא-נתונים -- אם האימות נכשל בזמן השמירה, תהליך העבודה נשמר ללא הפעלת ריפוי עצמי.

---

תיקונים מוצעים תקועים בהמתנה

אם approval_required הוא true (ברירת המחדל), גרסאות מוצעות ממתינות לסקירה אנושית. השתמש ב-workflow_version_list כדי לראות הצעות ממתינות וב-workflow_version_approve או workflow_version_reject כדי לפעול עליהן.

---

"Retry budget exhausted" / הסלמה בלתי ניתנת לפתרון

סוכן הריפוי השתמש בכל ניסיונות ההתערבות שלו (ברירת מחדל 3) מבלי לפתור את הבעיה. הוא מסלים כ-unresolvable ומפסיק לנסות לתקן.

פתרון:

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