הבנת סטטוסי רינדור: In Queue, In Progress, completed, failed, retrying

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

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

2. כאשר המשתמש מפעיל רינדור, הוא נוצר כ-⁦'initialized'⁩ ומוצג בגלריית הרינדורים כ-⁦"In Queue"⁩ עם דירוג בתור. אם מקום רינדור ה-HD החינמי תפוס כרגע, הרינדור עשוי להיווצר במקום זאת כ-⁦'on_hold'⁩ ולהיות מוצג כממתין, עם דירוג משוער, עד שהמקום יתפנה.

3. רינדור בתור נשאר בדרך כלל בתור עד שהוא מעובד; הוא אינו פג רק מעצם ההמתנה.

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

4. צינור הרינדור מנסה שוב אוטומטית. כל ניסיון נרשם כ-Render_Attempt נפרד עם מספר סידורי משלו, קבצי מידע ויומן שגיאות משלו, וחתימת זמן סיום משלו; רשומת הרינדור נושאת מונה ניסיונות. רינדור בסטטוס ⁦'retrying'⁩ פשוט הוחזר לתור לאחר ניסיון כושל — הוא שומר על הפרמטרים המדויקים שלו, עדיין תופס את מקומו בתור, ויפיק את התמונה המיועדת כאשר ניסיון יצליח; רינדורים מסתיימים routinely בניסיון שני או שלישי. אין חיוב על ניסיונות כושלים: החיוב סופר רינדור שהושלם אחד, ללא קשר למספר הניסיונות שנדרשו. מה לומר ללקוח: להניח לזה, הניסיון החוזר נפתר מעצמו בזרימת התור הרגילה. מתי לחקור לעומק: אם רינדור מתנדנד בין retrying ל-queued במשך שעות רבות, או צובר מונה ניסיונות גדול, הדבר מצביע либо על כך שהעיצוב consistently מפיל את המר�דר (יומני השגיאות לכל ניסיון יראו זאת), либо על כך שאין עובדי רינדור פועלים (ראו מאגר הידע על תור תקוע). ממשקי ה-API הארגוניים get_all_of_design ו-get_by_id מחזירים render_attempts בתוך התגובה, כולל נתיבי היומן של כל ניסיון, כך שהנדסה יכולה לאבחן רינדור מסוים בלי לשחזר אותו.