Codex ה‑retry backoff הזה מוגזם לגמרי: אחרי 403 ככל שמנסים שוב יותר זה נראה יותר כמו בוטינג

AIDO debug
, , , , , ,
1

לאחרונה, כשעבדתי עם Codex CLI מול upstream לא כל‑כך יציב, נתקלתי בבעיה ממש מצחיקה — אבל גם מאוד מעשית.

Codex כרגע מממש חיבור‑מחדש בסטרימינג כ־exponential backoff קשיח (hardcoded). הפעמים הראשונות נראות עוד סבירות, אבל בהמשך זה מתנפח בצורה מאוד מוגזמת:

  • בפעם ה־1 בערך 0.2 שניות
  • בפעם ה־5 בערך 3.2 שניות
  • בפעם ה־10 כבר יותר מדקה
  • ובהמשך זה אפילו יכול לעלות לעשרות דקות, פעם אחת כל כמה עשרות דקות

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

  • gateway שמדי פעם “מתחרפן”
  • ניתוב backend לא יציב
  • חלק משרתי תיווך תואמי OpenAI שמחזירים זמנית 403 / מצב המכסה לא עודכן
  • בפועל, אם מנסים עוד כמה פעמים — זה מהר מאוד חוזר לעבוד

כלומר, מה שבאמת צריך הוא:

  • שהמשתמש יחליט בעצמו על תדירות הניסיונות החוזרים
  • לפחות לאפשר ניסיון חוזר במרווח קבוע, למשל פעם ב־500ms
  • ולא להיות “חטוף” על ידי exponential backoff קשיח

מה שעוד יותר אבסורדי הוא ש‑Codex נותן למשתמש stream_max_retries, אבל לא נותן שליטה על מרווח הניסיון החוזר או על אסטרטגיית ה־backoff. זה מוביל לזה ש:
אפשר להגדיר את מספר הפעמים ל‑100, אבל אחרי הפעם ה־10 זמני ההמתנה מתחילים להיות לא הגיוניים, וזה לגמרי סותר את התרחיש של “עוד כמה ניסיונות וזה יעבור”.

כבר העליתי את הבעיה הזו ל‑upstream:

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

אם אפשר היה לתמוך במפורש ב‑TOML בתצורה כמו הבאה, זה לפחות היה מחזיר את הבחירה לידי המשתמש:

[model_providers.custom]
stream_max_retries = 100
stream_retry_delay_ms = 500
stream_retry_backoff = "fixed"

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