Michael Johnsonאם קריאה אל Durable Object הסתיימה בכשל רשת, בעבר המפתחים נדרשו לא פעם להחליט אם לשלוח אותה שוב. החל מ־5 בנובמבר 2026, ה־runtime של Cloudflare מבצע חלק מהניסיונות החוזרים האלה: הוא מנסה שוב אוטומטית קריאות מסוימות שנכשלו ל־fetch() ול־RPC דרך stub. לכן השאלה החשובה לקוד היישום מדויקת יותר כעת: האם מתודה מסוימת יכולה לפעול שוב בבטחה?
התשובה תלויה במקום שבו הקשר נותק. ה־runtime מנסה שוב אוטומטית קריאות מסוימות, תוך שמירה כברירת מחדל על ההגנה מפני ביצוע כפול. במקרה של אי־ודאות במסירה, הוא משתמש באותו מזהה בקשה, והאובייקט דוחה את הניסיון החוזר אם כבר קיבל את הניסיון הראשון. למתודה שסומנה במפורש באמצעות retryable() יש התנהגות שונה: אפשר להריץ אותה שוב גם אם הניסיון הראשון כבר הגיע לאובייקט. לכן יש לסמן כך רק פעולות שבטוח לחזור עליהן מבחינת המצב ותופעות הלוואי.
מה בדיוק ה־runtime מנסה שוב
לפי ההודעה של Cloudflare מ־5 בנובמבר, הניסיונות החוזרים חלים על קריאות fetch() ו־RPC אל Durable Object, שנשלחות מ־Worker או מ־Durable Object אחר. לקריאות דרך stub מוגדרים כברירת מחדל ניסיון ראשון ועד ארבעה ניסיונות חוזרים; ניסיונות חדשים לא מתחילים יותר מ־10 שניות לאחר תחילת הקריאה.
התנאי הוא שגיאה המסומנת ב־.retryable. לדוגמה, ייתכן שהבקשה לא הגיעה לאובייקט משום שהוא הופעל מחדש או הועבר למיקום אחר. ה־runtime עשוי לנסות שוב גם אם החיבור נותק ולא ניתן לדעת אם האובייקט הספיק לקבל את הבקשה. אם האובייקט כבר קיבל אותה, ניסיון חוזר עם אותו מזהה נדחה. ה־runtime אינו מנסה שוב בעקבות שגיאות שהקוד של Durable Object זרק, שגיאות עם .overloaded או תגובות HTTP כגון 500: אלה תשובות של המטפל, ולא שגיאות מסירה.
למה מסירה חוזרת אינה זהה להרצה חוזרת של פעולה
שליחה חוזרת של הבקשה אינה כשלעצמה גורמת להרצה שנייה של המתודה. כשיש אי־ודאות בתוצאה, ה־runtime שולח את הבקשה עם אותו מזהה; אם האובייקט קיבל את הניסיון המקורי, הוא דוחה את הניסיון החוזר. כך נמנעת הרצה נוספת של המתודה במצב הרגיל, למשל חיוב חוזר או יצירת רשומה נוספת בעקבות כשל רשת יחיד.
הגבול משתנה כשהמתודה מסומנת באמצעות retryable() מתוך cloudflare:durable-objects. במקרה כזה, האובייקט רשאי להריץ את המתודה שוב אם ייתכן שהניסיון הראשון כבר התחיל. Cloudflare מביאה שתי דוגמאות: קביעת כמות מוגדרת למוצר היא פעולה אידמפוטנטית; הגדלת הכמות באחד אינה כזו. חזרה על הפעולה הראשונה קובעת שוב את אותו הערך, ואילו חזרה על השנייה מוסיפה יחידה נוספת.
יש לבדוק לא רק את מצב האחסון הסופי, אלא גם את כל ההשפעות של המתודה. אם ניסיון חוזר יוצר תשלום נוסף, שולח הודעה או מפעיל פעולה חיצונית, העובדה שמצב ה־Durable Object נותר זהה אינה הופכת את החזרה לבטוחה. הסימון מתאים כאשר ניסיון חוזר אינו משנה את משמעות התוצאה ואינו משכפל תופעות לוואי.
מתי אידמפוטנטיות מפורשת מועילה
קביעת ערך, כתיבת תמונת מצב או עדכון שדה לערך ידוע מניבים לעיתים קרובות אותה תוצאה גם לאחר ניסיון חוזר. במתודות כאלה, retryable() עשוי לאפשר לקריאה להסתיים בהצלחה לאחר ניתוק שאירע אחרי שהעיבוד כבר החל.
פעולות כמו „להוסיף”, „ליצור עוד אחד”, „לחייב” ו„לשלוח” דורשות בדרך כלל הגנה אחרת. לפני שמתירים הרצה חוזרת, יש לוודא שהפעולה העסקית מזהה כפילויות או בנויה כך שניסיון חוזר לא ייצור השפעה נוספת. שם הפונקציה לבדו אינו ערובה: יש לבדוק את כל שינויי המצב והפעולות החיצוניות שבתוך המתודה.
ל־retryable() תפקיד מוגבל: הוא מתיר הרצה חוזרת כאשר אי אפשר לקבוע אם הקריאה הראשונה הגיעה. הוא אינו משנה את סוגי השגיאות שה־runtime מגיב להן ואינו מגדיל את מספר הניסיונות. הסימון חל על הפונקציה; גרסה שעוקפת או עוטפת את המתודה אינה יורשת אותו אוטומטית, אלא אם גם היא סומנה במפורש.
מה לבדוק בפרויקט שכבר פועל
המקום הסביר ביותר לבדיקה הוא לולאות הניסיונות החוזרים שהוספתם סביב קריאות ל־Durable Objects. כעת כל ניסיון כזה עשוי לכלול גם ניסיונות חוזרים של ה־runtime, ולכן מספר הקריאות הכולל עלול להיות גדול מזה שנקבע ביישום לבדו. Cloudflare ממליצה לצמצם את מספר הניסיונות העצמאי או להגדיר maxRetries: 0 עבור ה־stub אם הקוד שלכם מנהל את הניסיונות החוזרים.
מגדירים את המגבלות עבור stub מסוים בעת קריאה ל־get() או ל־getByName(). הפרמטר maxRetries קובע בין אפס לעשרה ניסיונות חוזרים לאחר הניסיון הראשון; timeoutMs קובע את משך הזמן שאחריו לא יתחילו ניסיונות חדשים, בין 500 ל־60,000 מילישניות. ההגדרות האלה חלות על הקריאות דרך ה־stub הזה. השימוש ב־retryable() ובאובייקט retry דורש Wrangler בגרסה 4.158.0 ואילך.
בדיקה מועילה כוללת שלוש שאלות לכל קריאה: האם היא יכולה לשנות את המצב יותר מפעם אחת; האם ניסיון חוזר שלה יפעיל שוב תופעות לוואי חיצוניות; והאם ליישום יש מדיניות ניסיונות חוזרים משלו. לאחר מכן החליטו אם ה־stub צריך להשתמש בערכי ברירת המחדל או במגבלות מותאמות אישית. עבור מתודות אידמפוטנטיות אפשר לשקול בנפרד סימון מפורש; עבור האחרות השאירו את ההגנה ובדקו את הטיפול בשגיאה כאשר תוצאת הניסיון הראשון אינה ידועה.
המשמעות: האחריות עוברת אל גבול המתודה
ניסיון חוזר אוטומטי מוציא חלק מלוגיקת הרשת מקוד היישום, אך ההחלטה אם מותר להריץ פעולה שוב נותרת תכונה של הפעולה עצמה. ה־runtime יכול לנסות שוב למסור את הבקשה בבטחה ולעצור אם אינו יודע אם הקריאה בוצעה. המפתח יכול להתיר הרצה חוזרת של המתודה, תוך אישור מפורש שהיא אינה משכפלת שינויי מצב או תופעות לוואי.
לכן כדאי לקרוא את העדכון כשינוי בחוזה שבין שכבת התעבורה למטפל. תחילה בדקו את לולאות הניסיונות החוזרים שלכם ואת האפשרות לשכפל תופעות לוואי; אחר כך הגדירו מגבלות ב־stubs המתאימים. כך אפשר לשלב עמידות מובנית בפני כשלים קצרים עם שליטה בפעולות שלהרצה שנייה שלהן יש מחיר ממשי.
