पुनः आरंभ के बाद पुनर्प्राप्ति

Gateway को पुनः आरंभ करने से एजेंट की स्थिति नष्ट नहीं होती। वार्तालाप, ट्रांसक्रिप्ट, निर्धारित कार्य, पृष्ठभूमि कार्य रिकॉर्ड और कतारबद्ध आउटबाउंड संदेश, सभी डिस्क पर रहते हैं, और किसी टर्न के बीच बाधित हुए कार्य का पता लगाकर Gateway के फिर से चालू होने के बाद उसे स्वचालित रूप से जारी रखा जाता है। पुनर्प्राप्ति हमेशा चालू रहती है और आमतौर पर किसी मैन्युअल हस्तक्षेप की आवश्यकता नहीं होती। बार-बार विफल होने वाली पुनर्प्राप्ति सीमित होती है और जब तक आप किसी सत्र की जाँच करके उसे बदल नहीं देते, तब तक उसे क्वारंटीन कर सकती है।

यह पृष्ठ बताता है कि पुनः आरंभ के बाद क्या बना रहता है, बाधित कार्य का पता कैसे लगाया जाता है, और स्वचालित बहाली कैसी होती है।

पुनः आरंभ के बाद क्या बना रहता है

सुचारु पुनः आरंभ पहले कार्य समाप्त होने की प्रतीक्षा करते हैं

अनुरोधित पुनः आरंभ (openclaw gateway restart, ऐसा कॉन्फ़िगरेशन परिवर्तन जिसके लिए पुनः आरंभ आवश्यक हो, या Gateway अपडेट) प्रगतिरत कार्य को तुरंत समाप्त नहीं करता। Gateway नया कार्य स्वीकार करना बंद करता है, फिर सक्रिय एजेंट टर्न और पृष्ठभूमि कार्यों के पूरा होने की प्रतीक्षा करता है, अधिकतम ड्रेन बजट तक (डिफ़ॉल्ट रूप से 5 मिनट)। इसलिए अधिकांश पुनः आरंभ किसी भी कार्य को बाधित नहीं करते।

केवल वह कार्य जो ड्रेन बजट के भीतर पूरा नहीं हो सकता (या जबरन पुनः आरंभ या क्रैश से बाधित कोई भी रन) निरस्त किया जाता है — और ऐसा होने से पहले, प्रत्येक प्रभावित सत्र को पुनर्प्राप्ति के लिए चिह्नित किया जाता है।

बाधित कार्य का पता कैसे लगाया जाता है

तीन पूरक तंत्र उन सत्रों को चिह्नित करते हैं जिनका टर्न पूरा नहीं हुआ:

• टर्न प्रवेश के समय: किसी मौजूदा मुख्य सत्र पर सामान्य टेक्स्ट टर्न के लिए, Gateway उपयोगकर्ता संदेश जोड़ता है, सत्र को चालू चिह्नित करता है और मॉडल या before_agent_reply हुक निष्पादन से पहले एक ही SQLite ट्रांज़ैक्शन में उसका पुनर्प्राप्ति डिलीवरी दावा दर्ज करता है। कंट्रोल UI यह कार्य started अभिस्वीकृति लौटाने से पहले करता है; चैनल डिस्पैच इसे तब करता है जब तैयार टर्न एजेंट रन को अपना लेता है। कमांड, अटैचमेंट, प्रति-टर्न ओवरराइड, लंबित डिलीवरी, पिछले निरस्तीकरण संकेत, Plugin-स्वामित्व वाले सत्र और निष्पादन हुक वाले टर्न अपने विशेष प्रवेश पथ बनाए रखते हैं। यदि कोई before_agent_reply हुक इंस्टॉल है, तो प्रवेश उसका चरण भी दर्ज करता है। पुनर्प्राप्ति किसी कॉल के बीच बाधित हुक को कभी दोबारा नहीं चलाती। बिना संभाला गया हुक पूरा होने पर उसका चेकपॉइंट परिणाम दर्ज करता है, लेकिन जब तक वह हुक सक्रिय रहता है, पुनर्प्राप्ति तब भी विफलता-सुरक्षित रहती है: कोई चेकपॉइंट यह प्रमाणित नहीं कर सकता कि पुनः आरंभ के बाद वही Plugin कोड और कॉन्फ़िगरेशन लोड हुआ है। संभाले गए टेक्स्ट और मौन परिणामों को नियतात्मक निपटान के लिए अलग-अलग चेकपॉइंट किया जाता है। पुराने संस्करणों द्वारा लिखे गए टिकाऊ पुनर्प्राप्ति दावों में स्रोत-स्वामित्व चिह्न नहीं होता, इसलिए अपग्रेड के दौरान उन पर भी वही विफलता-सुरक्षित हुक जाँच लागू होती है।
• शटडाउन के समय: पुनः आरंभ ड्रेन के दौरान, सक्रिय रन वाले प्रत्येक सत्र पर रन निरस्त होने से पहले सत्र स्टोर में पुनर्प्राप्ति चिह्न लगाया जाता है।
• स्टार्टअप के समय: Gateway सत्र स्टोर में ऐसे सत्र खोजता है जो अब भी स्वयं को चालू बताते हैं लेकिन नई प्रक्रिया में उनका कोई सक्रिय स्वामी नहीं है। इससे वे गंभीर क्रैश और प्रक्रिया समाप्तियाँ पकड़ में आती हैं जिनमें कोई शटडाउन कोड नहीं चला। पुराने ट्रांसक्रिप्ट लॉक फ़ाइलों को भी उसी समय साफ़ किया जाता है।

स्वचालित बहाली

स्टार्टअप के कुछ सेकंड बाद, Gateway प्रत्येक चिह्नित सत्र को एक कृत्रिम सिस्टम संदेश के साथ फिर से डिस्पैच करता है, जो एजेंट को बताता है कि उसका पिछला टर्न पुनः आरंभ के कारण बाधित हुआ था और उसे मौजूदा ट्रांसक्रिप्ट से जारी रखना है। यदि कोई अंतिम उत्तर पहले ही बन चुका था लेकिन पहुँचाया नहीं गया था, तो उसका टेक्स्ट शामिल किया जाता है ताकि एजेंट कार्य दोबारा करने के बजाय उसे पहुँचा सके।

स्टार्टअप समायोजन अस्थायी विफलताओं का अधिकतम तीन बार एक्सपोनेंशियल बैकऑफ़ के साथ पुनः प्रयास करता है। अलग से, प्रत्येक बाधित मुख्य-सत्र चक्र के पास शुल्कित स्वचालित डिस्पैच के तीन प्रयासों का टिकाऊ बजट होता है, जो Gateway के पुनः आरंभों के बीच बना रहता है। OpenClaw डिस्पैच से पहले एक प्रयास शुल्कित करता है, जब Gateway अनुरोध को स्वीकार करने से पहले स्पष्ट रूप से अस्वीकार करता है तो शुल्क वापस करता है, और कार्य दोबारा चलने से बचाने के लिए डिस्पैच के बाद परिणाम अनिश्चित होने पर शुल्क बनाए रखता है। सत्र पर पहले से स्वामित्व रखने वाला अग्रभूमि कार्य उसके पूरा होने तक स्वचालित पुनर्प्राप्ति को बाहर रखता है।

टिकाऊ बजट समाप्त होने के बाद, अनंत लूप में जाने के बजाय सत्र को टूम्बस्टोन किया जाता है। विफल सत्र की जाँच करें और प्रतिस्थापन शुरू करने के लिए /new या /reset का उपयोग करें। openclaw doctor --fix ऐसे पुराने निरस्त ध्वज की मरम्मत कर सकता है जो टूम्बस्टोन से टकराता है, लेकिन यह उस पुनर्प्राप्ति चक्र को दोबारा सक्षम नहीं करता।

हर पुनः प्रयास एक ही टिकाऊ डिस्पैच पहचानकर्ता का पुनः उपयोग करता है, इसलिए अस्पष्ट कनेक्शन विफलता उसी पुनर्प्राप्ति को दो बार शुरू नहीं कर सकती। पूर्ण और बहाल न किए जा सकने वाले कंट्रोल UI टर्न भी सीमित टिकाऊ इडेम्पोटेंसी टूम्बस्टोन बनाए रखते हैं, जिससे दोबारा कनेक्ट होने वाला आउटबॉक्स अनुरोध को फिर से निष्पादित किए बिना उन्हें हटा सकता है।

केवल संदेश-टूल वाले उत्तर दूसरी टिकाऊ सहसंबद्धता का उपयोग करते हैं। अंतिम समान-वार्तालाप प्रेषण के चैनल तक पहुँचने से पहले, Gateway सटीक सत्र और स्रोत टर्न पर एक अनसुलझा डिलीवरी उद्देश्य दर्ज करता है। पुष्टि की गई प्रदाता सफलता इसे टिकाऊ डिलीवरी रसीद में बदल देती है; पुष्टि की गई विफलता इसे साफ़ कर देती है। पुनर्प्राप्ति टूल दोबारा चलाए बिना डिलीवरी रसीद को पूर्ण करती है। यदि कोई क्रैश प्रदाता के परिणाम को अज्ञात छोड़ देता है, तो पुनर्प्राप्ति किसी बाहरी प्रभाव को दोबारा चलाने के बजाय विफलता-सुरक्षित रहती है।

पहुँचाया गया उत्तर उसके स्रोत संदेश ID के साथ ट्रांसक्रिप्ट में भी प्रतिबिंबित होता है। अंतिम प्रतिबिंब अलग रसीद कुंजी का उपयोग करते हैं, इसलिए समान प्रदाता इडेम्पोटेंसी कुंजी वाला प्रगति प्रेषण अंतिम चिह्न को छिपा नहीं सकता। पुराने टर्न के प्रगति प्रेषण और रसीदें वर्तमान टर्न को पूरा नहीं कर सकतीं। केवल टिकाऊ चैनल-इनग्रेस दावे संदेश-कार्रवाई प्राधिकार बहाल कर सकते हैं। बहाल किया गया रन मूल स्रोत-डिलीवरी मोड और स्रोत सहसंबंध बनाए रखता है, जिसमें अनुरोधकर्ता की पहचान और समान-चैनल/थ्रेड प्रतिबंध शामिल हैं, ताकि पुनर्प्राप्ति के दौरान एक और पुनः आरंभ होने पर भी वही रसीद प्रामाणिक बनी रहे। पुनर्निर्माण योग्य चैनल प्राधिकार के बिना केवल संदेश-टूल वाला टर्न विफलता-सुरक्षित रूप से विफल किया जाता है और उसे एकबारगी पुनः प्रेषण सूचना मिलती है।

बहाल करने से पहले, Gateway जाँचता है कि ट्रांसक्रिप्ट का अंतिम भाग वहाँ से जारी रखने के लिए सुरक्षित है। यदि ऐसा नहीं है (उदाहरण के लिए, टर्न किसी पुराने लंबित अनुमोदन पर समाप्त हुआ), तो सत्र को आँख मूँदकर दोबारा नहीं चलाया जाता; इसके बजाय एजेंट उपयोगकर्ता से अंतिम अनुरोध फिर से भेजने के लिए कहने वाली एक छोटी सूचना पोस्ट करता है। WebChat के लिए, वह सूचना सीधे सत्र इतिहास में लिखी जाती है ताकि दोबारा कनेक्ट होने के बाद भी दिखाई दे।

OpenClaw बाधित केवल-पठन कोड मोड कार्य का पुनर्निर्माण भी कर सकता है। कोड मोड इन रन को पुनः आरंभ-सुरक्षित चिह्नित करता है और दुष्प्रभाव डालने वाले कैटलॉग टूल या Plugin नेमस्पेस को निष्पादित होने से पहले अस्वीकार करता है। यदि पुनः आरंभ wait नियंत्रण पर होता है, तो नया Gateway ट्रांसक्रिप्ट से टर्न का पुनर्निर्माण करता है और पुनर्निर्मित निष्पादन को पुनः आरंभ-सुरक्षित बने रहने के लिए बाध्य करता है, भले ही मॉडल उस ध्वज को छोड़ दे या साफ़ कर दे। होस्ट संपूर्ण पुनर्निर्मित टर्न को ऑडिट किए गए केवल-पठन कोर टूल और स्पष्ट रूप से पुनः चलाने योग्य Plugin टूल तक सीमित करता है, यहाँ तक कि पुनः आरंभ के बाद कोड मोड अक्षम होने पर भी। दुष्प्रभाव डालने वाला कार्य डुप्लिकेट लेखन का जोखिम लेने के बजाय पुनः प्रेषण सूचना द्वारा सुरक्षित रहता है।

उप-एजेंट

उप-एजेंट रन साझा SQLite स्थिति डेटाबेस में स्थायी रूप से संग्रहीत किए जाते हैं, इसलिए उप-एजेंट रजिस्ट्री प्रक्रिया के बाद भी बनी रहती है। बूट पर रजिस्ट्री बहाल की जाती है और बाधित उप-एजेंट सत्रों को उनके मूल कार्य संदर्भ के साथ फिर से शुरू किया जाता है। दो सुरक्षा उपाय लागू होते हैं:

• 2 घंटे से अधिक पहले बाधित हुए रन को फिर से शुरू करने के बजाय अंतिम रूप दिया जाता है, ताकि रात भर बंद रहा Gateway पुराने कार्य को पुनर्जीवित न करे।
• जो सत्र बार-बार पुनर्प्राप्त होने में विफल रहता है, उसे अटका हुआ मानकर टूम्बस्टोन किया जाता है ताकि पुनर्प्राप्ति अनंत लूप में न चल सके।

पृष्ठभूमि कार्य

पृष्ठभूमि कार्य रजिस्ट्री SQLite-समर्थित है और बूट पर तथा आवधिक अंतराल पर समायोजित की जाती है: पूर्ण रन द्वारा दर्ज टिकाऊ परिणाम पुनर्प्राप्त किए जाते हैं, और जिन रन की स्वामी प्रक्रिया गायब हो गई है उन्हें अनुग्रह अवधि के बाद हमेशा के लिए अटके रहने के बजाय खोया हुआ चिह्नित किया जाता है।

एजेंट द्वारा अनुरोधित पुनः आरंभ

जब एजेंट स्वयं पुनः आरंभ ट्रिगर करता है (कॉन्फ़िगरेशन परिवर्तन लागू करना, Gateway अपडेट करना या स्पष्ट पुनः आरंभ अनुरोध), तो प्रक्रिया बंद होने से पहले SQLite में एक पुनः आरंभ सेंटिनल लिखा जाता है। बूट के बाद Gateway परिणाम को मूल चैट में वापस पोस्ट करता है और एकबारगी निरंतरता टर्न डिस्पैच करता है, ताकि एजेंट ठीक वहीं से कार्य जारी रखे जहाँ उसने छोड़ा था, उसी चैनल और थ्रेड पर।

सेंटिनल के टाइप किए गए SQLite कॉलम पुनः आरंभ प्रबंधन के लिए प्रामाणिक हैं; इसका payload_json मान केवल पुनः चलाने/डीबग करने की छाया है। रनटाइम बिना किसी फ़ाइल फ़ॉलबैक के SQLite स्थिति को पढ़ता, लिखता और साफ़ करता है। संग्रहण परिवर्तन के दौरान, स्टार्टअप पर और Doctor के माध्यम से एक सीमित स्थिति माइग्रेशन चलता है, ताकि अपडेट के बाद पुरानी प्रक्रिया द्वारा छोड़े गए मान्य restart-sentinel.json को सुरक्षित रखा जा सके। सामान्य पुनः आरंभ प्रबंधन जारी रहने से पहले माइग्रेशन टाइप की गई पंक्ति सत्यापित करता है और स्रोत फ़ाइल हटा देता है।

सुरक्षा उपाय और अवलोकनीयता

• क्रैश-लूप ब्रेकर: 5 मिनट के भीतर 3 अस्वच्छ बूट एक ब्रेकर सक्रिय करते हैं जो अगले बूट पर स्वतः-प्रारंभ होने वाली सहायक सेवाओं को रोक देता है, ताकि क्रैश होता Gateway अपनी समस्या को और न बढ़ाए। अस्वच्छ-बूट अवधि समाप्त होने पर यह पुनः सामान्य हो जाता है।
• मुख्य-सत्र प्रयास बजट: प्रत्येक बाधित चक्र के लिए तीन शुल्कित स्वचालित डिस्पैच प्रयास; समाप्त होने पर उस सत्र को जाँचकर बदले जाने तक टूम्बस्टोन कर दिया जाता है।
• मेट्रिक्स: पुनर्प्राप्ति गतिविधि Prometheus के माध्यम से openclaw_session_recovery_total और openclaw_session_recovery_age_seconds के रूप में निर्यात की जाती है।
• लॉग: पुनर्प्राप्ति निर्णय main-session-restart-recovery और subagent-interrupted-resume उप-प्रणालियों के अंतर्गत लॉग किए जाते हैं।

क्या बहाल नहीं किया जाता

• मुख्य-सत्र पुनर्प्राप्ति से बाहर रखे गए वे सत्र जिन्हें कोई अन्य स्वामी पहले से संभालता है: उप-एजेंट सत्र (उप-एजेंट पुनर्प्राप्ति), Cron सत्र (शेड्यूलर समय-सारिणी के अनुसार दोबारा चलाता है), और ACP-प्रबंधित सत्र (कनेक्टेड IDE या क्लाइंट बहाली का स्वामी होता है)।
• वे सत्र जिनके ट्रांसक्रिप्ट के अंतिम भाग को सुरक्षित रूप से जारी नहीं रखा जा सकता; इन्हें मौन पुनः निष्पादन के बजाय ऊपर वर्णित पुनः प्रेषण सूचना मिलती है।
• वह कार्य जिसे कभी प्रवेश नहीं मिला: ड्रेन अवधि के दौरान आने वाले संदेशों को बंद होती प्रक्रिया में चुपचाप कतारबद्ध करने के बजाय स्पष्ट पुनः आरंभ त्रुटि के साथ अस्वीकार किया जाता है।
• स्वतंत्र एम्बेडेड टर्न लंबित पुनः आरंभ पुनर्प्राप्ति वाले मुख्य सत्र का नियंत्रण नहीं ले सकते, क्योंकि वे Gateway के जीवनचक्र स्वामी को साझा नहीं करते। टर्न को Gateway के माध्यम से चलाएँ या वहाँ /new या /reset से रीसेट करें।