Сон и пробуждение Galaxy-приложения

Galaxy-приложение засыпает по простою вместе с галактикой-носителем, и на время сна его контейнер остановлен. Эта страница описывает, что именно останавливается, какие поля показывают настоящее состояние, чем приложение поднять и сколько это занимает.

Что останавливается · Поля состояния · Чем поднять · Логи · Окно по расписанию

Что останавливается во сне

Приложение живёт в контейнере на общем хосте — галактике. Спать могут обе части, и это разные состояния.

Постоянный том /data сон переживает. Пробуждение запускает тот же контейнер, а не создаёт новый, поэтому строки, которые приложение записало в свой поток вывода до сна, доступны и после пробуждения. Полностью новый контейнер появляется только при повторной загрузке кода — вот она журнал предыдущего контейнера не сохраняет.

Поля status и reachability отвечают на разные вопросы

Поле status в ответе GET /v1/infra/servers/:id — это состояние учётной записи приложения на платформе. Пробуждение переводит запись в running в конце, когда контейнер уже запущен, поэтому во время подъёма галактики запись остаётся в sleeping — на холодной машине это занимает минуты. Обратное расхождение тоже возможно: запись может числиться в running, пока контейнер уже не работает.

Поэтому рядом идёт блок reachability — он отвечает на вопрос «может ли приложение ответить прямо сейчас». Блок приходит только у приложения, kind равен GALAXY_APP, у остальных типов серверов там null.

{
  "success": true,
  "data": {
    "id": "e22bb297-8a0a-4597-9b42-47d059cd1090",
    "kind": "GALAXY_APP",
    "status": "sleeping",
    "reachability": {
      "effectiveStatus": "running",
      "hostStatus": "running",
      "hostTunnel": "CONNECTED",
      "container": "running",
      "forwarder": "active",
      "publicEntry": "live",
      "probe": "ok",
      "probedAt": "2026-08-12T13:24:58.117Z"
    }
  }
}

Показаны поля, относящиеся к сну. Полный ответ — GET /v1/infra/servers/:id.

Как складывается effectiveStatus:

Публичный вход проверяется отдельно. Контейнер и маршрутизация измеряются на самой галактике, а последний участок пути до https://app-XXXX.vibecode.bitrix24.tech — это туннель приложения на шлюзе, и на галактике его не видно: запущенный юнит маршрутизации означает, что его запустили, а не что он дозвонился до шлюза. Поэтому приложение с живым контейнером и активной маршрутизацией, но без туннеля, отвечает unreachable, а не running — снаружи такой адрес не обслуживается. Если состояние шлюза узнать не удалось, publicEntry равен unknown и вердикт остаётся прежним: «не смогли посмотреть» — это не «ничего не работает».

Важно: живой опрос хоста платформа делает только когда галактика работает и соединена с платформой. Спящую галактику чтение состояния не будит, поэтому у спящей галактики container и forwarder всегда unknown, а probe равен host-down. Результат опроса платформа держит несколько секунд и отдаёт из памяти: опрос занимает канал команд, общий для всех приложений галактики, поэтому частый опрос состояния его не занимает.

Чем поднять спящее приложение

Ответ на вызов пробуждения приходит сразу, а не по готовности: у приложения нет своей облачной машины, и параметр ?wait=true ожидания здесь не даёт. Готовность проверяйте опросом GET /v1/infra/servers/:id по полю reachability.effectiveStatus — значение waking означает, что галактика ещё загружается.

Сколько ждать: подъём холодной галактики платформа ждёт до 15 минут и столько же готова ждать от вызывающего. Точное значение бюджета приходит в ответе на чтение логов спящего приложения, поле recovery.coldBootBudgetSeconds. Приложение на уже работающей галактике стартует за секунды.

Запрет пробуждения на хосте блокирует оба вызова, и /start его не снимает. Коды отказов — в таблице жизненного цикла на странице Galaxy-приложение.

Логи спящего приложения

Чтение GET /v1/infra/servers/:id/logs не будит ни приложение, ни галактику. Пока галактика спит или недоступна, ответ приходит со статусом 200, пустым массивом data.logs и двумя диагностическими полями.

{
  "success": true,
  "data": {
    "logs": [],
    "lines": [],
    "hint": "Galaxy host is asleep or unreachable, so the container log cannot be read right now. …",
    "recovery": {
      "reason": "The galaxy host carrying this container is not RUNNING + CONNECTED. …",
      "recoveryAction": "POST /v1/infra/servers/e22bb297-8a0a-4597-9b42-47d059cd1090/wake",
      "logsPreserved": true,
      "coldBootBudgetSeconds": 900,
      "poll": "GET /v1/infra/servers/e22bb297-8a0a-4597-9b42-47d059cd1090 (read `reachability`)",
      "wakeSchedule": { "available": true, "code": null }
    }
  }
}

Порядок действий: поднять приложение вызовом из recovery.recoveryAction, дождаться reachability.effectiveStatus равного running, повторить чтение логов.

Если поля recoveryAction в ответе нет — пробуждение откажут. Причина бывает двух родов, и hint называет ту, что сработала: либо дверь самого вызывающего (перечень ниже), либо запрет пробуждения на ХОСТЕ галактики — тогда ключ ни при чём, отказ придёт любому, и снимать запрет идёт владелец аккаунта. Вызов пробуждения в этом состоянии отвечает 403 SERVER_WAKE_BLOCKED, а пока у аккаунта просрочен доступ — 402 с кодом подписочной или тарифной стены. Окно по расписанию в этом состоянии создать можно, но хост оно не поднимет: запрет действует и на пробуждение по расписанию. Адреса пробуждения нет и в прозе: в этом состоянии ответ намеренно не называет ни POST …/wake, ни создание окна по расписанию — окно отбивает та же дверь. hint вместо адреса называет ровно то условие, которое сработало у него самого, а не список через «или», — и называет ПЕРВОЕ по порядку, в каком двери отбивают на самом деле. Порядок такой: у ключа обслуживания агента пробуждения нет в перечне маршрутов; при идущем удалении аккаунта пробуждение закрыто целиком, и смена ключа не поможет — заморожен владелец, а не ключ (доставка при этом остаётся открытой, см. ниже про второй путь); режим ключа переключается по Режиму доступа; ключу Коворка/Кода управляющий контур закрыт целиком; выключенный пилот галактик снимает администратор аккаунта; и последняя — доступ к приложению по связи, когда сервером владеет другой ключ: пробуждение проверяет владение строже, чем чтение журнала, поэтому такому вызывающему оно отвечает 404, и помогает только вызов ключом-владельцем сервера.

У части вызывающих выход всё же есть, и это не пробуждение. Ключу в режиме «только чтение» разрешён деплой на свой сервер, а деплой на спящее галакси-приложение поднимает хост сам. Тот же путь открыт ещё двум вызывающим, которым отказано в пробуждении: владельцу с идущим удалением аккаунта (заморозка стоит на плагине /v1/infra, а доставка живёт в другом) и тому, кого пустили по связи приложения (владение доставка проверяет мягче, чем пробуждение). Закрыт этот путь ровно трём: ключу Коворка/Кода, ключу обслуживания агента и вызывающему на аккаунте с выключенным пилотом галактик. Когда этот путь открыт, платформа называет его машинно — полем recovery.deliveryWakesHost (action — вызов, cost — цена словами), и цена тут не формальность: это выкладка кода и расход баланса Вайбкод, а не пробуждение. Звать его ради одного лишь чтения журнала не надо.

Открыт он не всем, и поле это показывает. Послабление для режима «только чтение» снимает у деплоя гейт РЕЖИМА и только его. Ключу Коворка/Кода управляющий контур закрыт целиком, при выключенном пилоте галактик отказывают любые не-GET по этому семейству, а у ключа обслуживания агента деплоя нет в его перечне маршрутов — всем троим POST …/deploy ответит отказом ровно так же, как и пробуждение. Поэтому проверяйте наличие deliveryWakesHost, а не предполагайте его: нет поля — открытого пути нет, и надо менять условие из hint. Важно: обратное тоже не гарантировано, ровно как у recoveryAction: наличие поля означает, что деплой не отбит ни по identity и режиму ключа, ни запретом на хосте. Оно не отвечает за состояние счёта НА МОМЕНТ ВЫЗОВА: заморозка баланса закрывает всё семейство /v1/infra целиком (402 ACCOUNT_FROZEN), и если она наступит после этого чтения, названный action получит именно её — тем более что деплой тратит баланс по построению. Пока условие не изменилось, повторять чтение логов в цикле смысла нет: ответ не изменится.

Окно пробуждения по расписанию

Окно пробуждения поднимает приложение по расписанию, без вызова руками. Доступно оно не каждому приложению, и проверять это следует по ответу платформы, а не по общему правилу: поле recovery.wakeSchedule в ответе на чтение логов спящего приложения даёт готовый ответ для конкретного приложения, а при отказе — его код.

Ответ этот — и про приложение, и про вызывающего сразу. Создание окна остаётся записью, поэтому ключу в режиме «только чтение», ключу Коворка/Кода и порталу с выключенным пилотом галактик оно откажет; в этих состояниях поле приходит available: false с кодом отбившей двери. Пробуждение — хороший первый признак: нет recovery.recoveryAction — окна этому вызывающему тоже не создать. Но признак этот не полный, потому что у окна есть две двери, которых у пробуждения нет: маршрут отсутствует в перечне ключа внешнего участника (EXTERNAL_COLLABORATOR_KEY_OUT_OF_SCOPE) и требует скоуп vibe:infra, которого пробуждение не требует (INFRA_SCOPE_REQUIRED). Любая из двух откажет в окне и тому, кто приложение разбудить может, — поэтому читайте само поле recovery.wakeSchedule, а не выводите его из recoveryAction.

Приложение в галактике отказ ALWAYS_ON_CONFLICT не получает: тариф оно не выбирает, а наследует от галактики, и режимом «Всегда онлайн» платформа его не считает. Это касается и агентов, и ботов: своего таймера простоя у них нет, но окно пробуждения им доступно на общих условиях. Остальные отказы окна при этом действуют — например, WAKE_SCHEDULE_GALAXY_DISABLED, когда на платформе выключена возможность для приложений галактики.

Список окон, создание, изменение и удаление — Пробуждение по расписанию.

Смотрите также

• Galaxy-приложение
• Разбудить сервер
• Логи сервера
• Получить сервер
• Пробуждение по расписанию
• Авторизация в приложении на Black Hole