पुनः आरंभ के बाद क्या सुरक्षित रहता है
व्यवस्थित पुनः आरंभ पहले कार्य समाप्त होने देते हैं
अनुरोधित पुनः आरंभ (openclaw gateway restart, कोई ऐसा कॉन्फ़िगरेशन परिवर्तन जिसके लिए
पुनः आरंभ आवश्यक हो, या Gateway अपडेट) चल रहे कार्य को तुरंत समाप्त नहीं करता। Gateway
नया कार्य स्वीकार करना बंद करता है, फिर सक्रिय एजेंट टर्न और
पृष्ठभूमि कार्यों के पूरा होने की प्रतीक्षा करता है, अधिकतम एक ड्रेन बजट तक (डिफ़ॉल्ट रूप से 5 मिनट)। इसलिए अधिकांश
पुनः आरंभ किसी भी कार्य को बाधित नहीं करते।
केवल वह कार्य जो ड्रेन बजट के भीतर पूरा नहीं हो सकता (या जबरन पुनः आरंभ अथवा क्रैश से बाधित कोई रन)
निरस्त किया जाता है — और ऐसा होने से पहले, प्रत्येक
प्रभावित सत्र को पुनर्प्राप्ति के लिए चिह्नित किया जाता है।
बाधित कार्य का पता कैसे लगाया जाता है
तीन पूरक तंत्र उन सत्रों को चिह्नित करते हैं जिनका टर्न पूरा नहीं हुआ:- टर्न स्वीकार करते समय: किसी मौजूदा मुख्य सत्र के सामान्य टेक्स्ट टर्न के लिए,
Gateway उपयोगकर्ता संदेश जोड़ता है, सत्र को चल रहा चिह्नित करता है और
मॉडल या
before_agent_replyहुक के निष्पादन से पहले एक SQLite ट्रांज़ैक्शन में उसका पुनर्प्राप्ति डिलीवरी दावा रिकॉर्ड करता है। Control UI यह कार्यstartedअभिस्वीकृति लौटाने से पहले करता है; चैनल डिस्पैच इसे तब करता है जब तैयार टर्न एजेंट रन को अपनाता है। कमांड, अटैचमेंट, प्रति-टर्न ओवरराइड, लंबित डिलीवरी, पूर्व निरस्तीकरण संकेत, Plugin-स्वामित्व वाले सत्र और निष्पादन हुक वाले टर्न अपने विशिष्ट स्वीकार-पथ बनाए रखते हैं। यदि कोईbefore_agent_replyहुक इंस्टॉल है, तो स्वीकार प्रक्रिया उसका चरण भी रिकॉर्ड करती है। पुनर्प्राप्ति कॉल के बीच में बाधित किसी हुक को कभी दोबारा नहीं चलाती। किसी अनहैंडल्ड हुक के पूरा होने पर, उसका चेकपॉइंट उस परिणाम को रिकॉर्ड करता है, लेकिन जब तक वह हुक सक्रिय रहता है, पुनर्प्राप्ति फिर भी विफलता-सुरक्षित रहती है: कोई चेकपॉइंट यह सिद्ध नहीं कर सकता कि पुनः आरंभ के बाद वही Plugin कोड और कॉन्फ़िगरेशन लोड हुआ था। हैंडल किए गए टेक्स्ट और मौन परिणामों को नियतात्मक निपटान के लिए अलग-अलग चेकपॉइंट किया जाता है। पुराने संस्करणों द्वारा लिखे गए टिकाऊ पुनर्प्राप्ति दावों में स्रोत-स्वामित्व चिह्न नहीं होता, इसलिए अपग्रेड के दौरान उन पर भी वही विफलता-सुरक्षित हुक जाँच लागू होती है। - शटडाउन के समय: पुनः आरंभ ड्रेन के दौरान, सक्रिय रन वाले प्रत्येक सत्र पर रन निरस्त होने से पहले सत्र स्टोर में पुनर्प्राप्ति चिह्न लगाया जाता है।
- स्टार्टअप के समय: Gateway उन सत्रों के लिए सत्र स्टोर स्कैन करता है जो अब भी स्वयं को चल रहा बताते हैं, लेकिन नई प्रक्रिया में उनका कोई सक्रिय स्वामी नहीं होता। इससे वे हार्ड क्रैश और प्रक्रिया-समापन पकड़ में आते हैं जिनमें कोई शटडाउन कोड नहीं चला था। पुराने ट्रांसक्रिप्ट लॉक फ़ाइलों को उसी समय साफ़ किया जाता है।
स्वचालित पुनरारंभ
स्टार्टअप के कुछ सेकंड बाद, Gateway प्रत्येक चिह्नित सत्र को एक कृत्रिम सिस्टम संदेश के साथ फिर डिस्पैच करता है, जो एजेंट को बताता है कि उसका पिछला टर्न पुनः आरंभ से बाधित हुआ था और उसे मौजूदा ट्रांसक्रिप्ट से जारी रखना है। यदि कोई अंतिम उत्तर पहले ही तैयार हो चुका था लेकिन डिलीवर नहीं हुआ था, तो उसका टेक्स्ट शामिल किया जाता है ताकि एजेंट कार्य दोबारा करने के बजाय उसे डिलीवर कर सके। पुनर्प्राप्ति घातांकीय बैकऑफ़ के साथ अधिकतम 3 बार पुनः प्रयास करती है। प्रत्येक पुनः प्रयास एक ही टिकाऊ डिस्पैच पहचानकर्ता का पुनः उपयोग करता है, ताकि कोई अस्पष्ट कनेक्शन विफलता एक ही पुनर्प्राप्ति को दो बार शुरू न कर सके। पूर्ण और फिर शुरू न किए जा सकने वाले Control UI टर्न सीमित टिकाऊ आइडेम्पोटेंसी टूम्बस्टोन भी बनाए रखते हैं, जिससे पुनः कनेक्ट होने वाला आउटबॉक्स अनुरोध को फिर निष्पादित किए बिना उन्हें हटा सके। केवल संदेश-टूल वाले उत्तर दूसरी टिकाऊ सहसंबंध व्यवस्था का उपयोग करते हैं। उसी वार्तालाप में अंतिम भेजाव चैनल तक पहुँचने से पहले, Gateway ठीक उसी सत्र और स्रोत टर्न पर एक अनसुलझा डिलीवरी आशय रिकॉर्ड करता है। प्रदाता की पुष्टि की गई सफलता इसे टिकाऊ डिलीवर रसीद में बदल देती है; पुष्टि की गई विफलता इसे साफ़ कर देती है। पुनर्प्राप्ति टूल फिर चलाए बिना डिलीवर रसीद पूरी करती है। यदि कोई क्रैश प्रदाता के परिणाम को अज्ञात छोड़ देता है, तो पुनर्प्राप्ति किसी बाहरी प्रभाव को दोबारा चलाने के बजाय विफलता-सुरक्षित रहती है। डिलीवर किया गया उत्तर उसके स्रोत संदेश ID के साथ ट्रांसक्रिप्ट में भी प्रतिबिंबित किया जाता है। अंतिम प्रतिबिंब अलग रसीद कुंजी का उपयोग करते हैं, इसलिए समान प्रदाता आइडेम्पोटेंसी कुंजी वाला प्रगति भेजाव अंतिम चिह्न को छिपा नहीं सकता। पुराने टर्न के प्रगति भेजाव और रसीदें वर्तमान टर्न को पूरा नहीं कर सकतीं। केवल टिकाऊ चैनल-इनग्रेस दावे संदेश-कार्रवाई प्राधिकार पुनर्स्थापित कर सकते हैं। फिर शुरू किया गया रन मूल स्रोत-डिलीवरी मोड और स्रोत सहसंबंध बनाए रखता है, जिसमें अनुरोधकर्ता की पहचान और समान-चैनल/थ्रेड प्रतिबंध शामिल हैं, ताकि पुनर्प्राप्ति के दौरान एक और पुनः आरंभ होने पर भी वही रसीद प्रामाणिक बनी रहे। पुनर्निर्माण योग्य चैनल प्राधिकार के बिना केवल संदेश-टूल वाला टर्न विफलता-सुरक्षित रूप से विफल होता है और उसे एकबारगी पुनः भेजने की सूचना मिलती है। फिर शुरू करने से पहले, Gateway जाँचता है कि ट्रांसक्रिप्ट का अंतिम भाग वहाँ से जारी रखने के लिए सुरक्षित है। यदि वह सुरक्षित नहीं है (उदाहरण के लिए, टर्न किसी पुराने लंबित अनुमोदन पर समाप्त हुआ हो), तो सत्र को बिना जाँच के फिर नहीं चलाया जाता; इसके बजाय एजेंट उपयोगकर्ता से अंतिम अनुरोध फिर भेजने के लिए एक संक्षिप्त सूचना पोस्ट करता है। WebChat के लिए, वह सूचना सीधे सत्र इतिहास में लिखी जाती है ताकि पुनः कनेक्ट होने के बाद भी वह दिखाई दे। OpenClaw बाधित केवल-पठन Code Mode कार्य का पुनर्निर्माण भी कर सकता है। Code Mode इन रन को पुनः आरंभ-सुरक्षित चिह्नित करता है और दुष्प्रभाव उत्पन्न करने वाले कैटलॉग टूल या Plugin नेमस्पेस को निष्पादित होने से पहले अस्वीकार करता है। यदि पुनः आरंभwait नियंत्रण पर होता है, तो नया Gateway ट्रांसक्रिप्ट से टर्न का पुनर्निर्माण करता है
और पुनर्निर्मित निष्पादन को पुनः आरंभ-सुरक्षित बने रहने के लिए बाध्य करता है, भले ही
मॉडल उस फ़्लैग को छोड़ दे या साफ़ कर दे। होस्ट पूरे पुनर्निर्मित
टर्न को ऑडिट किए गए केवल-पठन कोर टूल और स्पष्ट रूप से पुनः चलाने-सुरक्षित Plugin टूल तक सीमित करता है,
यह तब भी लागू होता है जब पुनः आरंभ के बाद Code Mode अक्षम हो। दुष्प्रभाव उत्पन्न करने वाला कार्य
डुप्लिकेट लेखन का जोखिम लेने के बजाय पुनः भेजने की सूचना से सुरक्षित रहता है।
उप-एजेंट
उप-एजेंट रन साझा SQLite स्थिति डेटाबेस में स्थायी रूप से संग्रहीत होते हैं, इसलिए उप-एजेंट रजिस्ट्री प्रक्रिया समाप्त होने के बाद भी बनी रहती है। बूट पर रजिस्ट्री पुनर्स्थापित की जाती है और बाधित उप-एजेंट सत्रों को उनके मूल कार्य संदर्भ के साथ फिर शुरू किया जाता है। दो सुरक्षा उपाय लागू होते हैं:- 2 घंटे से अधिक पहले बाधित हुए रन को फिर शुरू करने के बजाय अंतिम रूप दिया जाता है, ताकि रातभर बंद रहा Gateway पुराने कार्य को पुनर्जीवित न करे।
- जो सत्र बार-बार पुनर्प्राप्त होने में विफल होता है, उसे अटके हुए के रूप में टूम्बस्टोन किया जाता है ताकि पुनर्प्राप्ति हमेशा लूप में न चलती रहे।
पृष्ठभूमि कार्य
पृष्ठभूमि कार्य रजिस्ट्री SQLite-समर्थित है और बूट के समय तथा आवधिक अंतराल पर समन्वित की जाती है: पूर्ण हुए रन द्वारा रिकॉर्ड किए गए टिकाऊ परिणाम पुनर्प्राप्त किए जाते हैं, और जिन रन की स्वामी प्रक्रिया गायब हो गई है उन्हें हमेशा लटके रहने के बजाय एक अनुग्रह अवधि के बाद खोया हुआ चिह्नित किया जाता है।एजेंट द्वारा अनुरोधित पुनः आरंभ
जब एजेंट स्वयं पुनः आरंभ शुरू करता है (कॉन्फ़िगरेशन परिवर्तन लागू करना, Gateway अपडेट करना, या स्पष्ट पुनः आरंभ अनुरोध), तो प्रक्रिया समाप्त होने से पहले SQLite में एक पुनः आरंभ सेंटिनल लिखा जाता है। बूट के बाद Gateway परिणाम को मूल चैट में वापस पोस्ट करता है और एकबारगी निरंतरता टर्न डिस्पैच करता है, ताकि एजेंट ठीक वहीं से काम शुरू करे जहाँ उसने छोड़ा था, उसी चैनल और थ्रेड पर।सुरक्षा उपाय और प्रेक्षणीयता
- क्रैश-लूप अवरोधक: 5 मिनट के भीतर 3 अव्यवस्थित बूट एक अवरोधक सक्रिय करते हैं जो अगले बूट पर स्वतः-प्रारंभ होने वाली सहायक सेवाओं को रोकता है, ताकि क्रैश होता Gateway अपनी समस्या को और न बढ़ाए। अव्यवस्थित-बूट अवधि समाप्त होने पर यह पुनः सामान्य हो जाता है।
- मेट्रिक्स: पुनर्प्राप्ति गतिविधि
Prometheus के माध्यम से
openclaw_session_recovery_totalऔरopenclaw_session_recovery_age_secondsके रूप में निर्यात की जाती है। - लॉग: पुनर्प्राप्ति निर्णय
main-session-restart-recoveryऔरsubagent-interrupted-resumeउप-प्रणालियों के अंतर्गत लॉग किए जाते हैं।
क्या फिर शुरू नहीं किया जाता
- वे सत्र जिन्हें मुख्य-सत्र पुनर्प्राप्ति से बाहर रखा जाता है क्योंकि कोई अन्य स्वामी पहले से उन्हें संभालता है: उप-एजेंट सत्र (उप-एजेंट पुनर्प्राप्ति), cron सत्र (शेड्यूलर शेड्यूल के अनुसार फिर चलाता है), और ACP-प्रबंधित सत्र (कनेक्टेड IDE या क्लाइंट पुनरारंभ का स्वामी होता है)।
- वे सत्र जिनके ट्रांसक्रिप्ट के अंतिम भाग को सुरक्षित रूप से जारी नहीं रखा जा सकता; इन्हें चुपचाप फिर चलाने के बजाय ऊपर वर्णित पुनः भेजने की सूचना मिलती है।
- वह कार्य जिसे कभी स्वीकार ही नहीं किया गया: ड्रेन अवधि के दौरान आने वाले संदेशों को समाप्त होती प्रक्रिया में चुपचाप कतारबद्ध करने के बजाय स्पष्ट पुनः आरंभ त्रुटि के साथ अस्वीकार किया जाता है।