כשתרחיש ב־Make נעצר, לחיצה נוספת על Run once אינה תמיד הצעד הנכון. קודם צריך להבין מה נכשל, מה כבר בוצע, ואיזה עותק מתקנים. במדריך הזה ניצור שגיאת JSON מכוונת, נשמור את העבודה שנעצרה, נתקן אותה ידנית ואז נתקן בנפרד את המקור להרצות הבאות.
התרגיל בוצע ב־4 באוקטובר 2026 עם נתוני לימוד בלבד. שגיאת DataError נשמרה כהרצה לא מושלמת, נפתרה בניסיון ידני אחד, והחזירה recovery_result=reviewed. לאחר תיקון נפרד של המקור, גם הרצה חדשה של התרחיש הראשי הצליחה. כל הפעולות היו מקומיות בתוך Tools ו־JSON; לא נשלחו הודעות, לא נקראו Webhooks ולא בוצעה כתיבה ל־Sheets.
1. בונים מסלול קטן שקל לבדוק
בתרחיש בדיקה חדש הוסיפו Tools > Set variable. בשדה Variable name כתבו sample_json, וב־Variable value הזינו תחילה את האובייקט התקין שלמטה. אחריו הוסיפו JSON > Parse JSON ולבסוף Tools > Set variable נוסף, בשם recovery_result, שמקבל את status מפלט הפענוח. המספרים בתרגיל המצולם הם 1 למקור, 2 לפענוח ו־3 לתוצאה; אצלכם הם עשויים להיות שונים.
{
"request_id": "MAITZ-REC-001",
"status": "reviewed"
}בשלב ההכנה השתמשנו באפשרות של Make ללמוד את מבנה הפלט מהרצה עם JSON תקין, בלי ליצור Data structure בשם. אם status עדיין אינו זמין למיפוי, בדקו תחילה פענוח תקין כדי לחשוף את השדה. לפני ניסוי הכשל ודאו ש־JSON string במודול הראשי ממופה ל־sample_json, ולא נשאר טקסט קבוע. השאירו תזמון כבוי ובדקו מכסת קרדיטים ואחסון זמינה.
2. בוחרים לשמור את הכשל בלי ניסיון אוטומטי
פתחו Scenario settings והגדירו Store incomplete executions ל־Yes. השתמשו רק בדוגמאות הלא־אישיות שבתרגיל, כי נצטרך לראות את הקלט בהיסטוריה. בתרחיש שנבדק Keep data confidential נשאר No. אין לשנות כך הגדרות של תהליך שמכיל מידע אישי רק כדי שיהיה קל לצלם אותו.
הוסיפו מסלול טיפול בשגיאה ל־Parse JSON ובחרו Retry. בממשק שנבדק שם השדה היה Retry automatically; בחרו No ושמרו. כך אפשר לטפל ידנית בפריט שנשמר. אין צורך להפעיל את לוח הזמנים של התרחיש בשביל מסלול ההתאוששות שנראה כאן.
3. יוצרים כשל שאפשר להסביר
חזרו ל־Tools הראשון והחליפו את sample_json באובייקט הפגום שלמטה. השינוי היחיד הוא פסיק מיותר לפני הסוגר האחרון. שמרו את המודול ואת התרחיש ולחצו Run once. ב־History פתחו את ההרצה באמצעות קישור התאריך והשעה; בממשק שנבדק לא היה כפתור בשם Details.
{
"request_id": "MAITZ-REC-001",
"status": "reviewed",
}
התקבלה ההודעה “Source is not valid JSON.” עם הקוד DataError. המודול וההרצה הוצגו כ־Warning משום שמסלול Retry טיפל בכשל. מודול התוצאה עדיין לא בוצע. פתחו את Parse JSON והשוו את Input להודעה; אל תסתפקו בצבע הסטטוס.
4. מזהים את הפריט שנשמר
עברו ל־Incomplete executions ומצאו את הפריט לפי זמן ההרצה. בבדיקה הוא היה במצב Unresolved, עם Attempts=0 ומקף ב־Scheduled In. בפאנל השגיאה הופיע גם אישור שהנתונים נשמרו בתור, עם כפתור Resolve. אלה סימנים לכך שיש עבודה שממתינה לטיפול, ולא לכך שהפענוח הצליח.
פתחו את הפריט דרך קישור התאריך. בתצוגה שנבדקה לחיצה על תרשים התרחיש פתחה את עורך ההתאוששות; משם פתחנו את מודול Parse JSON שנכשל. ודאו שאתם מתקנים את הפריט הנכון ושאין ניסיון אחר שמתבצע במקביל. הודעה על תרחיש לא פעיל אינה סיבה להפעיל תזמון: השתמשנו בהרצה ידנית מתוך עותק ההתאוששות.
5. מתקנים את עותק ההתאוששות
בתוך Parse JSON של העותק שנשמר, החליפו את המיפוי בשדה JSON string בטקסט התקין, ללא הפסיק האחרון. לחצו Save במודול ואחר כך Run once בתוך אותו עותק. זהו תיקון נקודתי של הנתונים עבור הפריט שנעצר. אין להניח ששינוי במקור הראשי יעדכן אוטומטית את הקלט שכבר נשמר.
בניסיון שנבדק הופעלו רק Parse JSON ומודול Tools שאחריו; המקור לא הורץ מחדש. הפענוח החזיר request_id=MAITZ-REC-001 ו־status=reviewed, ומודול התוצאה החזיר recovery_result=reviewed. פתחו את הפלטים כדי לבדוק את הערכים עצמם.
6. מאמתים שהפריט נפתר
חזרו לרשימת Incomplete executions. אחרי התיקון הפריט עבר ל־Resolved, Attempts השתנה ל־1 ו־Scheduled In נשאר מקף. בבדיקתנו ניסיון ההתאוששות הסתיים ב־Success. אם הכשל עבר למודול מאוחר יותר, הטיפול עדיין אינו גמור וצריך לבדוק את נקודת העצירה החדשה.
השוו בין המצב ברשימה לבין פלט הפענוח ופלט התוצאה. סטטוס Resolved לבדו אינו מלמד מה היה כתוב בשדה. בתרגיל המקומי אפשר היה לבדוק את כל אלה בלי ליצור קובץ, שורה או הודעה בשירות חיצוני.
7. מתקנים בנפרד את התרחיש הראשי
השלמת הפריט שנשמר לא תיקנה את sample_json במקור. חזרו לתרחיש הראשי, פתחו את Tools הראשון והסירו שם את הפסיק המיותר. ודאו שב־Parse JSON הראשי נשאר מיפוי אל sample_json; הטקסט הקבוע שהזנו בעותק ההתאוששות אינו מחליף את המקור של האירוע הבא. שמרו את השינויים.
כעת לחצו Run once בתרחיש הראשי. בבדיקה הזאת כל שלושת המודולים פעלו, ההרצה הצליחה ו־recovery_result שוב היה reviewed. בסיום התרחיש נשאר Inactive, בלי הרצה פעילה ובלי ניסיון נוסף שממתין לפריט שתוקן. זהו ההבדל בין תיקון אירוע ישן לבין מניעת אותה תקלה באירוע הבא.
מה לוקחים לתהליך אמיתי
התרגיל מוכיח התאוששות מפענוח מקומי שגוי. הוא אינו מוכיח שאפשר לשלוח שוב מייל או להוסיף שוב שורה בלי כפילות. לפני חזרה על פעולה חיצונית, בדקו ביעד אם היא כבר הושלמה. Timeout יכול להופיע גם אחרי שהכתיבה התבצעה. אם אין ראיה ברורה, השאירו את התוצאה לבדיקה במקום להניח שנכשל.
גם Retry ו־Replay run אינם אותה פעולה. Replay משתמש בנתוני טריגר קודמים עם התרחיש הנוכחי, ולכן עלול לחזור על צעדים שכבר הצליחו. בתרגיל הזה השתמשנו בתיקון ידני מתוך הפריט שנשמר, ולא ב־Replay. ארבע ההרצות שתועדו כאן צרכו יחד 10 קרדיטים כלולים: 3 להכנה, 2 לכשל, 2 להתאוששות ו־3 להרצה החדשה. זו מדידה של התרגיל המסוים, לא מחיר מובטח לכל תרחיש.
קובצי התרגול והגרסה הקודמת
החבילה המעודכנת מכילה JSON תקין, טקסט JSON פגום במכוון, התוצאות שנצפו והוראות לקורא. היא הוכנה מקומית ואינה Blueprint רשמי או תרחיש לייבוא. אין בה כתובות הרצה, מזהי חשבון, לוגים פרטיים או נתוני לקוח.
חבילת Make הקודמת נשארת זמינה. תרגיל G5 שבה מבוסס על Data store ותוצאות צפויות, ואינו התרגיל המצולם והבדוק כאן. אם בוחרים ללמוד גם את התכנון הישן, מגבלת האחסון הבאה עדיין רלוונטית:
לפני יצירת המאגר, בדקו את ההקצאה הפנויה בחשבון: לפי תיעוד Make, מסלול Free כולל 1 MB לאחסון Data store, וגודל המאגר המזערי הוא 1 MB. לכן ההקצאה מספיקה למאגר אחד, ולא לכמה מאגרים נפרדים לתרגילי הסדרה במקביל. אם ההקצאה כבר בשימוש, עצרו לפני יצירת מאגר נוסף; אין למחוק נתונים קיימים או להפעיל שדרוג בתשלום רק כדי לבצע את התרגיל.
להקשר של חיבורים, מכסה ותחזוקה קראו את סקירת Make לעסקים קטנים.
מקורות רשמיים: Manage incomplete executions, Retry error handler, Scenario run replay, מרכז העזרה של Make: Data stores.
