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

הדוגמה המצורפת כוללת פונקציה תקולה ותיקון שנבדק מקומית. היא מדגימה כיצד להגדיר את התנהגות הטופס וכיצד לקרוא הודעות שגיאה. בדיקות הקוד אינן ציון בנצ׳מרק של Claude.

התקלה שהכנסנו לתרגיל

הפונקציה המקורית חיכתה לסיום fetch ומיד החזירה הצלחה. היא לא בדקה את קוד התגובה או את גוף התשובה. לפי תיעוד Fetch ב־MDN, תשובת HTTP כמו 503 אינה דוחה כשלעצמה את ההבטחה. צריך לבדוק את התגובה במפורש.

await fetcher('/api/leads', options);
return { ok: true }; // בתרגיל: הצלחה שגויה גם בתשובת 503

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

מה ביקשנו מ־Claude Code

ביקשנו שינוי ממוקד בפונקציית השליחה: להחזיר הצלחה רק אחרי תשובת HTTP תקינה עם saved: true ומזהה רשומה שאינו ריק; להעביר מפתח בקשה קבוע; ולהחזיר הודעה ברורה במקרה כשל. בדיקות הקבלה נשמרו מחוץ להיקף העריכה.

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

מצב שנבדקהתוצאה הנדרשת
השרת מחזיר 503אין הודעת הצלחה
תקלה ברשתמצב השמירה אינו מוצג כידוע
חסר אישור savedאין הודעת הצלחה
חסר מזהה רשומהאין הודעת הצלחה
יש אישור שמירה ומזהההצלחה ושליחת מפתח הבקשה
גוף התגובה אינו JSON תקיןהודעת כשל

התיקון הנוסף שנדרש אחרי שהבדיקות עברו

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

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

איך יודעים שהפנייה באמת קיימת

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

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

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

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

לפני שמחזירים את הטופס לאוויר

מסלול אבחון שאפשר לבצע בלי לשכתב את האתר

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

בדיקת הבקשה שיוצאת מהדפדפן

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

בדיקת התגובה בלי להניח שהכול נשמר

קוד HTTP וגוף תגובה מספרים דברים שונים. קוד תקין יכול להגיע מנתיב שמחזיר הודעה כללית לפני שמירה, וגוף שנראה כמו JSON יכול להיות דף שגיאה. בדוגמה שלנו הפונקציה דורשת גם אישור שמירה וגם מזהה. במערכת שלכם ההסכם עשוי להיות אחר, אבל הוא צריך להיות מוגדר. בקשו מ־Claude Code להצביע על המקום שבו השרת משלים את השמירה ועל התגובה שהדפדפן מקבל לאחר מכן.

בירור מול הרשומה בשרת

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

מה המשתמש צריך לראות בזמן השליחה

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

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

מסירת תיקון שאפשר לתחזק

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

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

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

החזרת הטופס לשימוש

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

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

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

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

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

שאלות נפוצות

האם תשובת 200 מוכיחה שהפנייה נשמרה?

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

האם כדאי פשוט לשלוח שוב כשהרשת נופלת?

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

אפשר לתקן את התקלה בשיעור אישי?

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