האם השליחה שפג תוקפה באמת שמרה את העבודה שלכם?

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

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

התחילו מהטקסט ומחותמת הזמן

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

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

חפשו את התוצאה בתצוגה של האפליקציה עצמה

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

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

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

החליטו אם שליחה שנייה בטוחה

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

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

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

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

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

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

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

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