"OpenClaw תחקיר תקלה בשרשרת פרסום הפוסטים בדפדפן: מתיקון מערכתי מ־fields are required ועד stale ref"

AIDO ניפוי באגים
, , ,
1

תחקיר תקלה בשרשרת פרסום פוסטים בדפדפן OpenClaw: מ־fields are required ועד stale ref — תיקון מערכתי

המאמר הזה הוא תחקיר מלא של פתרון תקלות בפרודקשן אמיתי, כשהמטרה היא להסביר בבירור: “למה זה התפוצץ, למה קודם לא הייתה בעיה, ומה בדיוק שונה הפעם”, ולתת צעדי תיקון שניתן לשחזר ולבצע שוב.

קהל יעד:

  • מי שמשתמש/ת בכלי browser בתוך OpenClaw לאוטומציה של פרסום פוסטים/מילוי טפסים
  • מי שנתקל/ה ב־fields are required‏, Element \"eXX\" not found or not visible‏, No tool call found for function call output ...
  • מי שרוצה לשדרג “כיבוי שריפות זמני” ל"פתרון יציב, ניתן לשימוש חוזר"

א. תסמינים והשפעה עסקית

1) השגיאות המרכזיות

במהלך התקלה הופיעו שלושה סוגי שגיאות טיפוסיים:

  1. fields are required
  2. Element \"e92\" not found or not visible. Run a new snapshot to see current page elements.
  3. 400 No tool call found for function call output with call_id ...

2) התנהגות ברמת העסק

  • העמוד נפתח
  • ה־DOM מצליח לעשות snapshot
  • ברגע שמגיעים ל־act/fill או לפעולת הזנת ערך לנוד, שירות השליטה בדפדפן נופל עם שגיאה ועוצר
  • התהליך של פרסום פוסטים בין אתרים (Linux.do / V2EX / 2libra / iSharkFly) לא יכול לרוץ ברצף

קל מאוד לטעות ולחשוב שזו “בעיה בהרשאות החשבון” או “הקשר (context) ארוך מדי”, אבל במקרה הזה הוכח שזה לא כך.

ב. ציר זמן (נקודות מפתח)

  • 2026-02-23 12:44 (CST) בערך: התקנה/עדכון של OpenClaw במחשב המקומי ל־2026.2.22-2
  • לאחר מכן הופיעו הרבה שגיאות browser: fields are required
  • בהמשך, הופיע stale ref: Element \"e92\" not found or not visible
  • בסשנים היסטוריים היה גם: No tool call found for function call output ...
  • בסוף, אחרי תאימות פרוטוקול + מנגנון גיבוי ל־stale ref — חזר פרסום הפוסטים לעבוד

הבהרה:

  • No tool call found ... ו־fields are required אינן אותה בעיה.
  • הקטנת חלון ה־context (למשל 1048576 → 200000) לא מתקנת ישירות את שתי שגיאות התשתית הללו.

ג. פירוק סיבת השורש

סיבת שורש A: אי־תאימות בפרוטוקול fill (הראשונה שהתפוצצה)

צורת בקשת פעולה נפוצה בצד upstream היא:

{
  "kind": "fill",
  "ref": "e57",
  "text": "..."
}

בעוד שהמימוש הנוכחי של ה־router יותר מצפה ל:

{
  "kind": "fill",
  "fields": [
    { "ref": "e57", "type": "text", "value": "..." }
  ]
}

כאשר fields לא מסופק ואין מיפוי תאימות לאחור, מיד מתקבלת fields are required.

סיבת שורש B: עמוד דינמי גורם ל־ref להיסחף (stale ref)

לדוגמה:

  • בזמן snapshot מתקבל e92
  • אחרי רינדור מחדש של רכיבים/החלפת שכבת overlay, e92 כבר לא תקף
  • פעולת type/fill הבאה עדיין מנסה להריץ עם ה־ref הישן, ומתקבלת not found or not visible

זה מאוד נפוץ ב־UI דינמי כמו שדה בחירת נוד ב־V2EX.

סיבת שורש C: No tool call found ... הוא חוסר יישור מצב בין session/tool-call

השגיאה הזו שייכת לחוסר עקביות בשרשרת session/tool-call (ה־call_id לא תואם), ולא כשל של פעולת DOM בדפדפן עצמה.

ד. מטרות ותכנון התיקון

המטרה היא לא “טלאי נקודתי”, אלא להפוך את שרשרת הפרסום ל־“תאימות + ריפוי עצמי + יכולת תצפית”:

  1. תאימות לצורת בקשות ישנה כדי למנוע fields are required
  2. התאוששות אוטומטית מ־stale ref, בלי לדרוש snapshot ידני בכל פעם
  3. גם אם הפעם השנייה נכשלת — עדיין יש גיבוי, כדי שהזרימה לא תקרוס בנקודת כתיבה קריטית

ה. שינויים בפועל (dist בזמן ריצה)

הבהרה: אחרי packaging של OpenClaw יש כמה תוצרים עם hash, וחובה להשלים את הענפים הקריטיים בסנכרון, כדי להימנע ממצב שבו בזמן ריצה נטען bundle שלא תוקן.

1) שכבת תאימות ל־fill

בתוך case \"fill\" ב־/act נוספה שכבת מיפוי תאימות:

  • כש־fields חסר, ממירים אוטומטית {ref,text/value} ל־fields:[{ref,type:\"text\",value}]
  • ומספקים ברירת מחדל text עבור type של כל field

2) ניסיון חוזר אוטומטי ל־stale ref

ב־case \"type\" וב־case \"fill\":

  • תופסים Unknown ref / not found or not visible
  • מריצים אוטומטית פעם אחת snapshotRoleViaPlaywright({ refsMode: \"aria\" })
  • ואז מנסים שוב את הפעולה המקורית

3) שכבת גיבוי שנייה (החיזוק המרכזי הפעם)

אם גם אחרי “snapshot מחדש + ניסיון חוזר” עדיין יש כשל בגלל stale ref:

  • עבור type: מנסים לכתוב ערך ישירות ל־document.activeElement ולשגר input/change
  • עבור fill: בתרחיש של טקסט בשדה יחיד, משתמשים באותו גיבוי דרך activeElement

זה מכסה תרחיש נפוץ: “הפוקוס עדיין על שדה היעד, אבל ה־ref הישן כבר לא תקף”.

4) קבצים מעורבים

  • /opt/homebrew/lib/node_modules/openclaw/dist/routes-CmNAokG-.js
  • /opt/homebrew/lib/node_modules/openclaw/dist/routes-FGJF5gtZ.js
  • /opt/homebrew/lib/node_modules/openclaw/dist/pi-embedded-helpers-CNhhELVT.js
  • /opt/homebrew/lib/node_modules/openclaw/dist/pi-embedded-helpers-DxTyisc4.js

ו. צעדי אימות (ניתנים לשחזור)

  1. להפעיל מחדש את ה־gateway, לוודא שהתהליך החדש נכנס לתוקף (PID משתנה)
  2. להפעיל את אותו תהליך אוטומטי של פרסום פוסט באותו מסלול
  3. לצפות בלוגים ולבדוק אם עדיין מופיעים:
    • fields are required
    • Element \"eXX\" not found or not visible
  4. לאמת את התוצאה העסקית: האם הפוסט באמת נוצר בהצלחה

תוצאה הפעם:

  • מסלול התקלה שוחזר, פרסום הפוסט הצליח.

ז. למה “לפני יומיים היה תקין, והפעם צריך לשנות כל כך הרבה”?

המסקנה חד־משמעית:

  1. שינוי גרסה הגדיל את פערי הפרוטוקול

    • הגרסה המקומית הנוכחית: openclaw@2026.2.22-2
    • בגרסה הזו, נקודת הכניסה של fill מחמירה יותר לגבי צורת fields[]

  2. אותה בעיה חייבת להיות מתוקנת בכמה כניסות dist

    • זה נראה כמו “שינינו הרבה קבצים”, אבל בפועל זה “אותה לוגיקה קיימת כפול במספר תוצרי bundle”

  3. סחיפת ref בעמודים דינמיים היא סיכון מובנה

    • זה שלא נתקלו בזה קודם לא אומר שזה לא קיים
    • ברגע שהעמוד מרנדר מחדש לעיתים תכופות יותר — זה מתפוצץ מרוכז

לכן זה לא “בעיה של קונפיג בלבד”, אלא פער כפול: “תאימות פרוטוקול + יציבות UI דינמי”.

ח. המלצות להמשך (מניעת רגרסיה)

1) המלצות בשכבת הפרוטוקול

  • להגדיר בפרוטוקול פעולות ה־browser את ה־canonical schema של fill
  • לשמור חלון תאימות לאחור ל־schema הישן, ולהוסיף בלוגים רמזי מיגרציה

2) המלצות בשכבת הביצוע

  • להוסיף מתג קונפיגורבילי ל־type/fill/click שמבצע snapshot מקדים (מצב יציבות גבוה)
  • להוסיף לוגים מובנים (structured) לענף ה־stale-ref retry (כדי לזהות אם הופעל גיבוי)

3) המלצות בשכבת התפעול

  • אחרי כל שדרוג להריץ E2E מינימלי: open → snapshot → fill → submit
  • לחבר שגיאות מפתח (fields are required, Unknown ref) לאזעקות/התראות

4) המלצות בשכבת הסשן

  • No tool call found ... צריך בדיקה נפרדת (שלמות סשן/עקביות replay), ולא לערבב עם בעיות DOM בדפדפן

ט. צ’קליסט דיבאג (לעצמי בעתיד)

אם פוגשים בעיה דומה, ללכת לפי הסדר:

  1. קודם להפריד סוג שגיאה (פרוטוקול/DOM/session)
  2. לבדוק את חותמת הזמן של הלוגים האחרונים, לא להסתמך על שגיאה ישנה ולטעות באבחון
  3. לוודא שצורת ה־payload תואמת לגרסה הנוכחית
  4. להוסיף ל־stale ref: “snapshot + ניסיון חוזר + גיבוי activeElement”
  5. להפעיל מחדש ולוודא שתהליך חדש טען את הקוד החדש
  6. לבצע בדיקה חוזרת באותו מסלול, ולוודא הצלחה עסקית ולא רק היעלמות השגיאה

י. סיכום

התיקון הזה לא “מסתיר את השגיאה”, אלא השלים את שרשרת הפרסום לשלוש שכבות חוסן:

  • שכבה 1: תאימות פרוטוקול (מניעת חוסר התאמה מבני)
  • שכבה 2: התאוששות אוטומטית (ניסיון חוזר אחרי snapshot)
  • שכבה 3: גיבוי קלט (כתיבה דרך activeElement)

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

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