פתרון נפחים וטיפול בכשל

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

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

בדיקת כתיבה חלקית

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

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

זהות בניסיון חוזר

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

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