פתרון בקשות חוזרות

בדיקת ID קיים חייבת להקדים בדיקת capacity. אחרת שירות מלא יפסיק לענות לבקשות חוזרות למרות שהוא כבר מחזיק את התוצאה שלהן. עבור ID חדש נחזיר Busy או CapacityExceeded ולא נפנה רשומה ישנה בלי שחוזה retention מתיר זאת.

הקטע הבא מחליף את תחילת submit לאחר בדיקת ID קיים. הוא מדגים את נקודת ההחלטה, ואינו משנה את חוזה המודל לשמירה עמידה.

if self.entries.len() >= 100 {
    return Err("capacity exceeded");
}

כדי לשלב אותו נשנה את טיפוס התוצאה ל־Result<Reply, &'static str> ונעטוף את שאר התוצאות ב־Ok. ה־lookup יוכל להשתמש ב־get ולהעתיק את u64 בלבד, בלי לשכפל payload. במקרה שהאחסון poisoned נחזיר מצב תשתית נפרד, מפני ש־Unknown של בקשה אינו אותו דבר כמו חוסר יכולת לסמוך על האינדקס.

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

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