פתרון התאוששות בלי לנחש מה קרה

היעד ללא deduplication נכשל בחלון after_effect. הקריאה הראשונה משנה total, הjournal אינו שומר result והקריאה השנייה משנה אותו שוב. הintent המקומי מאפשר לדעת שהתכוונו לבצע; הוא אינו מוכיח שהצד השני לא ביצע.

הבדיקה של שתי קריסות מרחיבה את הלולאה לכל זוג cutים, מפעילה attempt פעמיים ואז עם none. נשמרים אותם invariants: total שווה 100, קיימת רשומת יעד אחת והתוצאה המקומית תואמת. הקריסות במודל נמצאות בין transactions, ולכן הבדיקה אינה מוכיחה אטומיות של storage אמיתי.

הconflict נבדק אחרי הצלחה של מזהה 7 עם amount של 100. ניסיון עם אותו מזהה ו101 חייב להיכשל, גם אחרי restart. החזרת התוצאה הישנה בלי לציין conflict תסתיר בקשה שאינה זהה, וביצוע חדש יפר את הבטחת המזהה.

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

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