Що зберігається після перезапуску
Коректні перезапуски спочатку очікують завершення роботи
Запитаний перезапуск (openclaw gateway restart, зміна конфігурації, що потребує
перезапуску, або оновлення Gateway) не припиняє поточну роботу негайно.
Gateway перестає приймати нову роботу, а потім очікує завершення активних
ходів агентів і фонових завдань у межах часу очікування (типово 5 хвилин).
Тому більшість перезапусків узагалі нічого не переривають.
Припиняється лише робота, яку неможливо завершити в межах часу очікування
(або будь-який запуск, перерваний примусовим перезапуском чи аварійним
завершенням), — і перш ніж це станеться, кожен відповідний сеанс позначається
для відновлення.
Як виявляється перервана робота
Сеанси, хід яких не завершився, позначаються трьома взаємодоповнювальними механізмами:- Під час прийняття ходу: для звичайного текстового ходу в наявному
основному сеансі Gateway додає повідомлення користувача, позначає сеанс як
активний і записує його заявку на доставку відновлення в межах однієї
транзакції SQLite до виконання моделі або обробника
before_agent_reply. Інтерфейс керування робить це до повернення підтвердженняstarted; диспетчеризація каналу — коли підготовлений хід приймає запуск агента. Команди, вкладення, перевизначення для окремого ходу, доставки в очікуванні, попередні ознаки переривання, сеанси, якими володіють плагіни, і ходи з обробниками виконання зберігають власні спеціалізовані шляхи прийняття. Якщо встановлено обробникbefore_agent_reply, під час прийняття також записується його фаза. Відновлення ніколи не запускає повторно обробник, перерваний посеред виклику. Після завершення необробленого обробника його контрольна точка фіксує цей результат, але відновлення все одно завершується безпечною відмовою, доки цей обробник залишається активним: контрольна точка не може підтвердити, що після перезапуску завантажено той самий код і конфігурацію плагіна. Оброблені текстові й безмовні результати фіксуються окремо для детермінованого завершення. Стійкі заявки на відновлення, записані старішими версіями, не мають маркера належності джерелу, тому під час оновлення до них застосовується така сама перевірка обробника з безпечною відмовою. - Під час завершення роботи: протягом очікування перед перезапуском кожен сеанс з активним запуском отримує маркер відновлення у сховищі сеансів до припинення запуску.
- Під час запуску: Gateway перевіряє сховища сеансів на наявність сеансів, які досі позначені як активні, але не мають активного власника в новому процесі. Так виявляються аварійні завершення та примусові припинення, за яких код завершення роботи не виконувався. Одночасно видаляються застарілі файли блокування транскриптів.
Автоматичне відновлення
За кілька секунд після запуску Gateway повторно диспетчеризує кожен позначений сеанс із синтетичним системним повідомленням, яке повідомляє агенту, що його попередній хід було перервано перезапуском і що слід продовжити роботу з наявного транскрипту. Якщо остаточну відповідь уже було створено, але не доставлено, її текст додається, щоб агент міг доставити її замість повторного виконання роботи. Відновлення повторюється до 3 разів з експоненційною затримкою. Кожна повторна спроба використовує один стійкий ідентифікатор диспетчеризації, тому неоднозначний збій з’єднання не може двічі запустити те саме відновлення. Завершені ходи інтерфейсу керування та ходи, які неможливо відновити, також зберігають обмежені стійкі маркери ідемпотентності, завдяки чому вихідна черга після повторного підключення може вилучити їх без повторного виконання запиту. Відповіді, надіслані лише засобом повідомлень, використовують другу стійку кореляцію. Перш ніж остаточне надсилання в межах тієї самої розмови потрапить до каналу, Gateway записує невирішений намір доставки для точного сеансу й початкового ходу. Підтверджений успіх постачальника перетворює його на стійку квитанцію про доставку; підтверджений збій видаляє його. Відновлення завершує обробку квитанції про доставку без повторного запуску засобів. Якщо після аварійного завершення результат у постачальника невідомий, відновлення завершується безпечною відмовою замість повторного виконання зовнішньої дії. Доставлена відповідь також дублюється в транскрипті з ідентифікатором початкового повідомлення. Остаточні дублікати використовують окремий ключ квитанції, тому надсилання перебігу роботи з тим самим ключем ідемпотентності постачальника не може приховати остаточний маркер. Надсилання перебігу роботи й квитанції з попередніх ходів не можуть завершити поточний хід. Лише стійкі заявки на вхідні повідомлення каналу можуть відновити повноваження на дії з повідомленнями. Відновлений запуск зберігає початковий режим доставки джерела та початкову кореляцію, зокрема ідентичність запитувача й будь-яке обмеження тим самим каналом або потоком, тому та сама квитанція залишається авторитетною, навіть якщо під час відновлення відбудеться ще один перезапуск. Хід, що використовує лише засіб повідомлень і для якого неможливо відновити повноваження каналу, завершується безпечною відмовою та отримує одноразове сповіщення про повторне надсилання. Перед відновленням Gateway перевіряє, чи безпечно продовжувати з кінця транскрипту. Якщо ні (наприклад, хід завершився на застарілому очікуванні схвалення), сеанс не запускається повторно без перевірки; натомість агент публікує коротке сповіщення з проханням до користувача повторно надіслати останній запит. Для WebChat це сповіщення записується безпосередньо в історію сеансу, щоб воно залишалося видимим після повторного підключення. OpenClaw також може відновлювати перервану роботу лише для читання в режимі коду. Режим коду позначає такі запуски як безпечні для перезапуску та відхиляє засоби каталогу з побічними ефектами або простори імен плагінів до їх виконання. Якщо перезапуск відбувається на елементі керуванняwait, новий Gateway відновлює хід із його
транскрипту й примусово зберігає безпечність відновленого виконання для
перезапуску, навіть якщо модель пропускає або скидає цей прапорець. Хост
обмежує весь відновлений хід перевіреними основними засобами лише для читання
та явно безпечними для повторного виконання засобами плагінів, зокрема якщо
режим коду вимкнено після перезапуску. Робота з побічними ефектами залишається
захищеною сповіщенням про повторне надсилання, щоб уникнути ризику дублювання
запису.
Субагенти
Запуски субагентів зберігаються у спільній базі даних стану SQLite, тому реєстр субагентів зберігається між процесами. Під час запуску реєстр відновлюється, а перервані сеанси субагентів продовжуються з початковим контекстом завдання. Застосовуються два запобіжні механізми:- Запуски, перервані понад 2 години тому, завершуються замість відновлення, щоб Gateway, який не працював уночі, не відновлював застарілу роботу.
- Сеанс, який неодноразово не вдається відновити, позначається стійким маркером як заблокований, щоб відновлення не могло тривати нескінченно.
Фонові завдання
Реєстр фонових завдань зберігається в SQLite та узгоджується під час запуску й через періодичні проміжки часу: відновлюються стійкі результати, записані завершеними запусками, а запуски, процес-власник яких зник, після пільгового періоду позначаються як втрачені замість нескінченного зависання.Перезапуски за запитом агента
Коли агент сам ініціює перезапуск (застосовує зміну конфігурації, оновлює Gateway або явно запитує перезапуск), перед завершенням процесу в SQLite записується маркер перезапуску. Після запуску Gateway публікує результат у початковому чаті та диспетчеризує одноразовий хід продовження, щоб агент продовжив роботу точно з місця зупинки в тому самому каналі й потоці.Запобіжні механізми та спостережуваність
- Запобіжник циклу аварійних завершень: 3 некоректні запуски протягом 5 хвилин активують запобіжник, який під час наступного запуску пригнічує автоматичний запуск допоміжних служб, щоб аварійний Gateway не посилював власний збій. Робота відновлюється після завершення вікна некоректних запусків.
- Метрики: дані про активність відновлення експортуються через
Prometheus як
openclaw_session_recovery_totalіopenclaw_session_recovery_age_seconds. - Журнали: рішення щодо відновлення записуються в підсистемах
main-session-restart-recoveryіsubagent-interrupted-resume.
Що не відновлюється
- Сеанси, виключені з відновлення основного сеансу, оскільки ними вже керує інший власник: сеанси субагентів (відновлення субагентів), сеанси cron (планувальник повторно запускає їх за розкладом) і сеанси під керуванням ACP (відновленням керує підключене IDE або клієнт).
- Сеанси, для яких неможливо безпечно продовжити з кінця транскрипту; замість непомітного повторного запуску вони отримують описане вище сповіщення про повторне надсилання.
- Робота, яку не було прийнято: повідомлення, що надходять протягом періоду очікування завершення, відхиляються з явною помилкою перезапуску, а не непомітно додаються до черги процесу, який завершується.