Widgets שבודקים את הצנרת שלהם: probe_url, agent מאמת ותיקון חינם אחד

הדרך הנפוצה ביותר ש-widget שנוצר נכשל לא הייתה bug בקוד שנוצר. זה היה endpoint שלא היה קיים.

המודל הגיע ל-URL מהזיכרון — או משורת directory שהקישור שלה הוא דף תיעוד, לא endpoint — ניחש את צורת התגובה, כתב קוד parsing זהיר נגד הניחוש, ושלח. מה שקיבלתם היה spinner נצחי או גרף ריק, בלי שום דבר על המסך שאומר למה.

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

בזמן כתיבה: probe_url

לבונה יש עכשיו כלי שעושה GET ל-endpoint ציבורי ללא מפתח עכשיו, דרך אותו server proxy ש-ctx.data.http() משתמש בו ב-runtime, ומחזיר את סטטוס HTTP האמיתי ואת גוף התגובה האמיתי.

הזהות הזו היא כל הנקודה. probe שמצליח הוא קריאת runtime שמצליחה. probe שנכשל הוא widget שהיה נשלח שבור — ונכשל עכשיו, כשעדיין נשאר תור לתקן, לא ב-canvas שלכם.

הוא יושב בתחתית סולם שהבונה מתבקש לעבוד ולא לחשוב מהזיכרון: venue reference docs קודם, ואז directory של 691 APIs ציבוריים ללא מפתח ב-47 קטגוריות, ניתן לחיפוש לפי נושא על שם ו תיאור כל רשומה — כי בקשות אמיתיות («זמני גאות», «איכות אוויר») לעיתים רחוקות מתאימות לקטגוריה שמישהו ינחש. ה-directory הזה תמיד זמין לבונה עכשיו, מה שבתוך scope, כי הוא ה-fallback האוניברסלי ללא מפתח. הקישורים שלו הם תיעוד, אז השלב האחרון תמיד אותו דבר: להסיק את ה-endpoint, ואז לבדוק.

«האם יש נתונים ל-X?» שאלה שעונים עליה בבדיקה, לא בחשיבה על אילו datasets כנראה קיימים. להגיע לסוף הסולם ולומר לא אחרי בדיקה אמיתית זה תוצאה טובה. לטעון מהזיכרון לא, וזה היה שגוי הרבה יותר ממה שהרגיש.

מיד אחרי כתיבה: המאמת

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

ראשית, תוצאת הכלי מציינת endpoints שלא נבדקו בתור הזה ואומרת לו לבדוק אותם כשעדיין נשארים rounds.

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

• Lint למודול לסוגי כשל שקטים by construction. export render חסר. קוד שלא parse. fetch או WebSocket גולמי ל-host צד שלישי, שה-sandbox חוסם — הכשל השקט ההרסני ביותר ב-widgets שנוצרו, כי שום דבר לא מופיע ב-console. URL תמונה או וידאו חיצוני שמוקצה ישירות ל-src. URL tile קשיח שמועבר לספריית maps, ש-mount ו-pan מושלמים בזמן שכל בקשת tile נדחית בשקט.
• Probe כל endpoint שהמודל דילג (עד חמישה למודול), וקריאת הפסק כמו שהמודל היה עושה: unreachable, או 4xx שאומר שה-URL או הפרמטרים שגויים.

בעיות אמיתיות קונות round תיקון in-turn אוטומטי אחד, עם פלט probe מצורף כראיה והוראה לתקן רק מה שצוין. ה-round הזה קורה כשהקשר המלא של ה-build עדיין חם — הרבה יותר זול משליחה שבורה והוצאת תור שלם אחר כך. אם המודל כותב מחדש את המודול באמצע, האימות שכבר רץ מוחלף והפסק שלו נזרק. verifier שנכשל פנימית מאמת נקי: הוא יכול לעכב build, לעולם לא לשבור אחד.

אם עדיין קורס: תיקון אחד, מוגבל בקשיחות

הקשר self-repair כבר הזין שגיאות runtime לתור הצ'אט הבא — אבל רק כששלחתם. widget שקרס שניות אחרי build נשאר שבור עד ששמתם לב, פתחתם מחדש את composer והקלדתם «זה שבור».

עכשיו runtime host מוציא תור fix אוטומטי אחד כש-build טרי קורס. תור אוטומטי הוא האפליקציה מוציאה את ה-credits או המפתח שלכם, אז הגבולות מכוונים להיות צרים:

• רק הגרסה ש-build AI זה עתה ייצר — crash בגרסה ישנה ששחזרתם, או בקוד שערכתם ידנית, לעולם לא מתאים;
• רק בתוך 45 שניות מאותו build, כי crash שעה אחר כך הוא מידע חדש בשבילכם, לא defect build ברור;
• פעם לגרסה, וגרסה שיוצרה על ידי תור auto-repair בעצמה לא זכאית. build אחד יכול להפעיל לכל היותר follow-up אוטומטי אחד — לעולם לא שרשרת של המודל משלם לעצמו להמשיך להיכשל.

תור התיקון נוסח כאילו האפליקציה מדווחת על defect, ומביא את אותה הוראה ככל מה שלמעלה: אם הכשל כולל data endpoint, probe לפני rewrite. תקן, שמור מה שעובד, אל תגדיל את scope של ה-widget.

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

אותה לולאה, כל mode

כל זה חי ב-module משותף, אז platform builds, bring-your-own-key builds בדפדפן, ו-build sweep בצד השרver מקבלים התנהגות זהה — אותם כלים, אותו probe formatting, אותו verifier, אותו repair budget. ה-modes לא יכולים diverge באילו כלים קיימים או באיזו קפדנות widget נבדק, כי יש רק implementation אחד לתשובה. זו גם הלולאה שהפיקה עשרה widgets לדוגמה שמגיעים עם הגרסה הבאה: הם נבנו בדיוק בזה, עם בדיוק הבדיקות האלה.

שום דבר מזה לא הופך מודל לנכון. זה הופך טעות ל-survivable, ולרוב invisible: ה-endpoint נבדק לפני שהקוד תלוי בו, הבדיקה רצה בין אם המודל רצה להריץ אותה או לא, וה-crash הראשון מקבל ניסיון fix כנה לפני שמגיע אליכם.

הפעל Nexow ובקש משהו obscure — זמני גאות, איכות אוויר, חגים ציבוריים. צפו ב-activity rail בודק את ה-endpoint לפני שכותב שורת parsing code אחת.