פס התקדמות למשימות רקע ב-Laravel וב-React

מדוע סרגל ההתקדמות למשימות רקע אינו תואם את המציאות

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

אם ההתקדמות בכל זאת זזה, היא משקרת אחרת — סופרת רשומות ולא את משקלן: אלף שורות קטנות חולפות בשנייה, ואילו פעולה כבדה אחת מחזיקה את הפס על 97% בדיוק כמו כל שאר החבילה.

הסיבה השנייה — עדכון הסטטוס חי בטרנזקציה נפרדת מהעבודה המועילה. ה-worker נפל בגלל timeout או לא נכנס לזיכרון — הרשומה נשארת במצב "מתבצעת", ואי אפשר להבחין בממשק בין משימה תקועה למשימה סתם ארוכה.

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

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

מה נותן מחוון מהימן של מצב משימות ארוכות

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

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

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

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

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

מצבי תצוגה של סרגל ההתקדמות: השוואת גישות

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

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

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

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

שלבי ההטמעה: מביקורת התור ועד מסירת הנוהל

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

1. ביקורת התור. מפרקים את מחזור החיים של משימת הרקע: אילו מטפלים קיימים, כמה צעדים יש בכל אחד, היכן המשימה יכולה להיות מופעלת מחדש, מבוטלת או נזרקת בגלל timeout. התוצאה — מפת מעברים, שעליה נבנה כל השאר.
2. סכמת סטטוסים. מתכננים סט סופי של מצבים (בתור, מתבצעת, צעד N מתוך M, מוכן, שגיאה) וכללי מעבר ביניהם. בנפרד מקבעים את ההתנהגות בהפעלה חוזרת — אחרת המשתמש יראה שתי התקדמויות עבור משימה אחת.
3. גבול הצעד. מסכימים מה נחשב לצעד: יחידת עבודה שאדם יכול לראות. צעד גדול מדי נותן פס "קפוא", צעד קטן מדי — רשומות מיותרות באחסון וגידול בעומס עליו.
4. אחסון המצב. בוחרים היכן חיה ההתקדמות: מטמון, טבלה במסד נתונים או תור הודעות. קובעים את תדירות הכתיבה ואת זמן החיים של הרשומה, כדי שנתונים לא יצטברו לאחר סיום המשימה.
5. העברה לממשק. מגדירים את ערוץ העדכון — סקר תקופתי או חיבור זורם — וכן את שחזור המצב ברענון הדף ואת ההתנהגות באובדן קשר. הלקוח לא אמור לראות התקדמות אפסית במשימה שכבר בוצעה.
6. בדיקה תחת עומס. מפעילים כמה משימות בו-זמנית ובודקים אם זמן התגובה לא גדל, אם עדכונים לא הולכים לאיבוד ואם הסטטוס הסופי תואם את תוצאת העיבוד בפועל.
7. מסירת הנוהל. מוסרים את סכמת הסטטוסים, את תצורת האחסון, את הכללים להוספת צעדים חדשים ואת הניתוח של תקלות אופייניות — מרגע זה הצוות מרחיב את ההתקדמות בלי מעורבותנו.

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

תצורות, סכמות ונהלים שנשארים בידי הצוות

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

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

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

מקרה בוחן: אי-התאמה בין המחוון לתור הוסרה בתוך שבועיים

לפני: המחוון קפא, והמשימות אבדו בשקט

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

אם המטפל נפל באמצע — למשל בגלל פורמט תאריך לא צפוי באחד הקבצים — מבחוץ שום דבר לא השתנה: הפס קפא על 60–70%, האדם המתין, והמשימה כבר הייתה מתה. ניתחנו את התקלות של חודש שלם: חלק מההפצות לא הגיעו לסיום, ואף אחת מהתקלות האלה לא הציגה שגיאה מפורשת בממשק.

אחרי: המצב מושווה לעובדה, ולא לציפייה

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

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

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

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

מה לעשות אם המחוון הוטמע ומציג ערכים שגויים

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

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

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

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

ספקות טכניים: אמינות, תחזוקה והפעלות חוזרות

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

מה קורה בעת תקלה של המטפל?

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

כמה משתמשים צופים במשימה בו-זמנית — האם זה מפריע?

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

האם הפתרון יעמוד בעומס שיא?

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

מה נשאר בתחזוקה לאחר המסירה?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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