Floci: להגדיר מה בדיקת הענן המקומי יכולה להוכיח

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

זה התרחיש שהייתי מביא אל Floci, אמולטור AWS בקוד פתוח. המקורות הראשוניים נבדקו ב-6 בנובמבר 2026. לא התקנתי את הפרויקט, לא השוויתי אותו בפועל ל-AWS ולא מדדתי ביצועים. הבדיקות המוצעות הן ניתוח שלי, לא תוצאות ניסוי.

לקרוא את שורת השירות

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

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

היעד המקומי צריך להיות מפורש

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

from urllib.parse import urlsplit

def require_local_endpoint(endpoint):
    u = urlsplit(endpoint)
    if (u.scheme != "http" or u.hostname != "127.0.0.1"
            or u.port != 4566 or u.username or u.password
            or u.path not in ("", "/") or u.query or u.fragment):
        raise ValueError("Expected the explicit loopback test endpoint")
    return endpoint

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

לבחור כשל לפני טענה

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

הודעה סינתטית ← תור ← עובד ← תוצאה שמורה
                              |
                        קריסה לפני אישור
                              |
                   מסירה חוזרת ובדיקת מספר התוצאות

חוזה נבחר ← השוואת AWS נפרדת ומורשית

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

ניתוב חשבון אינו אימות

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

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

מצב וגישה למארח

מדריך האחסון מבחין בין memory, persistent, hybrid ו-WAL. README מתאר אובדן מצב בעצירה ב-memory, כתיבה מיידית ב-persistent, שמירה תקופתית ב-hybrid ורישום שינויים לפני תשובה ב-WAL. אלה תכונות מתועדות, לא מדידת עמידות עצמאית.

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

תנאי הבחירה שלי

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