---
read_when:
    - आप जानना चाहते हैं कि Gateway को पुनः आरंभ करने से प्रगति पर चल रहा एजेंट कार्य नष्ट हो जाता है या नहीं
    - एजेंट का रन पुनः आरंभ, क्रैश या कॉन्फ़िग पुनः लोड होने के कारण बाधित हो गया था
    - Gateway के फिर से चालू होने के बाद स्वचालित सत्र पुनर्प्राप्ति को डीबग किया जा रहा है
summary: 'Gateway के पुनः आरंभ होने या क्रैश होने के बाद क्या जारी रहता है: बाधित एजेंट टर्न स्वचालित रूप से फिर शुरू होते हैं, सबएजेंट और पृष्ठभूमि कार्य पुनर्प्राप्त होते हैं, और कतारबद्ध डिलीवरी पूरी होती हैं'
title: पुनः आरंभ के बाद पुनर्प्राप्ति
x-i18n:
    generated_at: "2026-07-16T14:58:16Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: f2fc0263d792e78e75fb97be44671b44287d469b949e11640f11b6ff651dafb9
    source_path: gateway/restart-recovery.md
    workflow: 16
---

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

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

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

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

## व्यवस्थित पुनः आरंभ पहले कार्य समाप्त होने देते हैं

अनुरोधित पुनः आरंभ (`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](/hi/reference/code-mode)
कार्य का पुनर्निर्माण भी कर सकता है। Code Mode इन रन को पुनः आरंभ-सुरक्षित चिह्नित करता है और
दुष्प्रभाव उत्पन्न करने वाले कैटलॉग टूल या Plugin नेमस्पेस को निष्पादित होने से पहले अस्वीकार करता है। यदि पुनः आरंभ
`wait` नियंत्रण पर होता है, तो नया Gateway ट्रांसक्रिप्ट से टर्न का पुनर्निर्माण करता है
और पुनर्निर्मित निष्पादन को पुनः आरंभ-सुरक्षित बने रहने के लिए बाध्य करता है, भले ही
मॉडल उस फ़्लैग को छोड़ दे या साफ़ कर दे। होस्ट पूरे पुनर्निर्मित
टर्न को ऑडिट किए गए केवल-पठन कोर टूल और स्पष्ट रूप से पुनः चलाने-सुरक्षित Plugin टूल तक सीमित करता है,
यह तब भी लागू होता है जब पुनः आरंभ के बाद Code Mode अक्षम हो। दुष्प्रभाव उत्पन्न करने वाला कार्य
डुप्लिकेट लेखन का जोखिम लेने के बजाय पुनः भेजने की सूचना से सुरक्षित रहता है।

### उप-एजेंट

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

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

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

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

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

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

## सुरक्षा उपाय और प्रेक्षणीयता

- **क्रैश-लूप अवरोधक:** 5 मिनट के भीतर 3 अव्यवस्थित बूट एक अवरोधक सक्रिय करते हैं जो
  अगले बूट पर स्वतः-प्रारंभ होने वाली सहायक सेवाओं को रोकता है, ताकि क्रैश होता Gateway
  अपनी समस्या को और न बढ़ाए। अव्यवस्थित-बूट अवधि समाप्त होने पर यह पुनः सामान्य हो जाता है।
- **मेट्रिक्स:** पुनर्प्राप्ति गतिविधि
  [Prometheus](/hi/gateway/prometheus) के माध्यम से `openclaw_session_recovery_total` और
  `openclaw_session_recovery_age_seconds` के रूप में निर्यात की जाती है।
- **लॉग:** पुनर्प्राप्ति निर्णय
  `main-session-restart-recovery` और `subagent-interrupted-resume`
  उप-प्रणालियों के अंतर्गत लॉग किए जाते हैं।

## क्या फिर शुरू नहीं किया जाता

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