[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"docs-infra\u002Flifecycle\u002Frepair-status":3,"docs-tabs-infra\u002Flifecycle\u002Frepair-status":6},{"content":4,"lastmod":5},"\n## Статус восстановления\n\n`GET \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Frepair-status`\n\nВозвращает прогресс фонового восстановления туннеля, запущенного через [`POST \u002Frepair`](.\u002Frepair.md). Используется для периодического опроса: клиент видит текущий шаг (`wake` \u002F `serial_console` \u002F `ssh_install` \u002F `connect` \u002F …), финальный статус (`running` \u002F `done` \u002F `failed`) и в случае ошибки — поле `error`. Завершённые записи автоматически очищаются через 10 минут.\n\n## Параметры\n\n| Параметр | В | Тип | Обяз. | Описание |\n|----------|---|-----|:-----:|----------|\n| `id` | path | string (UUID) | да | ID сервера |\n\n## Примеры\n\n### curl — личный ключ\n\n```bash\ncurl -H \"X-Api-Key: YOUR_API_KEY\" \\\n  https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002FSERVER_ID\u002Frepair-status\n```\n\n### curl — OAuth-приложение\n\n```bash\ncurl -H \"X-Api-Key: YOUR_APP_KEY\" \\\n  -H \"Authorization: Bearer USER_SESSION_TOKEN\" \\\n  https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002FSERVER_ID\u002Frepair-status\n```\n\n### JavaScript — личный ключ\n\n```javascript\n\u002F\u002F Цикл опроса прогресса\nwhile (true) {\n  const res = await fetch(\n    `https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002F${serverId}\u002Frepair-status`,\n    { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }\n  )\n  const { data } = await res.json()\n\n  if (data.status === 'idle') { console.log('Ремонт не запущен'); break }\n  if (data.status === 'done')  { console.log(`Готово, шаг: ${data.step}`); break }\n  if (data.status === 'failed'){ console.error(`Ошибка на шаге ${data.step}: ${data.error}`); break }\n\n  console.log(`Шаг: ${data.step}`)\n  await new Promise(r => setTimeout(r, 10000))\n}\n```\n\n### JavaScript — OAuth-приложение\n\n```javascript\nconst res = await fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002F${serverId}\u002Frepair-status`,\n  {\n    headers: {\n      'X-Api-Key': 'YOUR_APP_KEY',\n      'Authorization': 'Bearer USER_SESSION_TOKEN',\n    },\n  }\n)\n```\n\n## Поля ответа\n\n| Поле | Тип | Описание |\n|------|-----|----------|\n| `success` | boolean | Всегда `true` при успехе |\n| `data.status` | string | `idle` (ремонт не запускался или очищен по таймауту), `running` (идёт), `done` (успешно), `failed` (провалился) |\n| `data.step` | string | Текущий\u002Fпоследний шаг: `wake`, `serial_console`, `ssh_install`, `connect`, `iptables`, `cleanup`, `done` |\n| `data.agentVersion` | string \\| null | Версия установленного агента (заполняется на шаге `ssh_install`) |\n| `data.wasSlept` | boolean | Был ли сервер в `sleeping` на момент запуска ремонта (тогда после `done` возвращается в `sleeping`) |\n| `data.error` | string | Текст ошибки, если `status: \"failed\"` |\n| `data.startedAt` | number | Timestamp старта ремонта (миллисекунды Unix) |\n\nДля `status: \"idle\"` возвращается только поле `status`, остальные поля отсутствуют.\n\n## Пример ответа\n\nРемонт не запускался:\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"status\": \"idle\"\n  }\n}\n```\n\nРемонт идёт, завершён шаг установки агента:\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"status\": \"running\",\n    \"step\": \"connect\",\n    \"agentVersion\": \"1.2.3\",\n    \"wasSlept\": false,\n    \"startedAt\": 1745312400000\n  }\n}\n```\n\nРемонт провалился:\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"status\": \"failed\",\n    \"step\": \"ssh_install\",\n    \"agentVersion\": null,\n    \"wasSlept\": false,\n    \"error\": \"SSH connection refused\",\n    \"startedAt\": 1745312400000\n  }\n}\n```\n\n## Пример ответа при ошибке\n\n404 — сервер не существует:\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"NOT_FOUND\",\n    \"message\": \"Server not found\"\n  }\n}\n```\n\n## Ошибки\n\n| HTTP | Код | Описание |\n|------|-----|----------|\n| 401 | `MISSING_API_KEY` | Не передан заголовок `X-Api-Key` |\n| 401 | `INVALID_API_KEY` | Неверный или просроченный API-ключ |\n| 404 | `NOT_FOUND` | Сервер не существует, удалён или принадлежит другому API-ключу |\n| 429 | `RATE_LIMITED` | Превышен общий лимит запросов платформы |\n\nПолный список общих ошибок API — [Ошибки](\u002Fdocs\u002Ferrors).\n\n## Известные особенности\n\n- **Порядок выполнения шагов:** `wake` (если сервер в `sleeping`) → `serial_console` (впрыск SSH-ключа через serial console Bitrix Cloud) → `ssh_install` (SSH-подключение и переустановка агента: скачивание бинаря, запись конфигурации, запуск сервиса) → `connect` (ожидание подключения агента к Gateway) → `iptables` (восстановление файрвола для BLACKHOLE) → `cleanup` (возвращение в `sleeping`, если сервер был спящим) → `done`.\n- **Сразу после [`POST \u002Frepair`](.\u002Frepair.md) статус уже `running`, не `idle`.** Статус выставляется в `running` синхронно при старте ремонта, поэтому первый же опрос `repair-status` (даже спустя миллисекунды) видит `running`. Раньше был короткий промежуток, где опрос мог увидеть `idle` и цикл опроса завершался преждевременно — теперь этого окна нет.\n- **TTL завершённых записей — 10 минут.** После этого повторный опрос вернёт `idle`. Если нужно подтвердить результат после TTL, смотрите на `blackholeStatus` в [`GET \u002Fv1\u002Finfra\u002Fservers\u002F:id`](\u002Fdocs\u002Finfra\u002Fservers\u002Fget) — если он `CONNECTED`, ремонт сработал.\n- **Одновременный ремонт невозможен** — на уровне сервиса стоит замок в памяти `repairingServers`. Повторный [`POST \u002Frepair`](.\u002Frepair.md) на сервере с уже идущим ремонтом корректно обрабатывается: второй вызов не запускает новую процедуру.\n\n## Смотрите также\n\n- [Восстановить туннель](.\u002Frepair.md) — `POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Frepair` — запуск ремонта.\n- [Получить сервер](\u002Fdocs\u002Finfra\u002Fservers\u002Fget) — проверить итоговый `blackholeStatus`.\n- [Обновить статус](.\u002Frefresh.md) — принудительно опросить провайдера после ремонта.\n","2026-06-29",{"repair.md":7},"\n## Восстановить туннель\n\n`POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Frepair`\n\nЗапускает фоновое восстановление туннеля Black Hole через serial console облачного провайдера. Используйте, когда виртуальная машина в `running`, но `blackholeStatus` застрял в `DISCONNECTED` или `WAITING` — то есть агент туннеля не подключается. Процедура проходит через serial console (минуя файрвол) и включает: впрыск SSH-ключа → SSH-подключение → полную переустановку агента с актуальной версией → ожидание переподключения. Длится до 2 минут. Сам вызов возвращается сразу и не ждёт завершения, прогресс смотрите через [`GET \u002Frepair-status`](.\u002Frepair-status.md).\n\n> **Это не способ снять `EXEC_BUSY`.** `\u002Frepair` — полная переустановка агента туннеля: живые процессы, запущенные через [`\u002Fexec`](..\u002Fdeploy\u002Fexec.md), при этом прерываются вместе с их побочными эффектами (например, открытая транзакция `COPY` во внешней базе повиснет и будет держать блокировки до таймаута на её стороне). Если сервер отвечает `409 EXEC_BUSY`, снимите лок вызовом [`DELETE \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Flock`](..\u002Fdeploy\u002Flock.md) — агент и запущенные процессы при этом не затрагиваются. `\u002Frepair` оставьте для случая по назначению: туннель действительно не подключается.\n\n## Параметры\n\n| Параметр | В | Тип | Обяз. | Описание |\n|----------|---|-----|:-----:|----------|\n| `id` | path | string (UUID) | да | ID сервера |\n\nТело запроса пустое.\n\n## Примеры\n\n### curl — личный ключ\n\n```bash\ncurl -X POST -H \"X-Api-Key: YOUR_API_KEY\" \\\n  https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002FSERVER_ID\u002Frepair\n```\n\n### curl — OAuth-приложение\n\n```bash\ncurl -X POST -H \"X-Api-Key: YOUR_APP_KEY\" \\\n  -H \"Authorization: Bearer USER_SESSION_TOKEN\" \\\n  https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002FSERVER_ID\u002Frepair\n```\n\n### JavaScript — личный ключ\n\n```javascript\n\u002F\u002F Запустить ремонт и периодически опрашивать статус\nawait fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002F${serverId}\u002Frepair`,\n  { method: 'POST', headers: { 'X-Api-Key': 'YOUR_API_KEY' } }\n)\n\nwhile (true) {\n  await new Promise(r => setTimeout(r, 10000))\n  const res = await fetch(\n    `https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002F${serverId}\u002Frepair-status`,\n    { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }\n  )\n  const { data } = await res.json()\n  console.log(`Шаг: ${data.step ?? data.status}`)\n  if (data.status === 'idle' || data.status === 'completed' || data.status === 'failed') break\n}\n```\n\n### JavaScript — OAuth-приложение\n\n```javascript\nawait fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002F${serverId}\u002Frepair`,\n  {\n    method: 'POST',\n    headers: {\n      'X-Api-Key': 'YOUR_APP_KEY',\n      'Authorization': 'Bearer USER_SESSION_TOKEN',\n    },\n  }\n)\n```\n\n## Поля ответа\n\n| Поле | Тип | Описание |\n|------|-----|----------|\n| `success` | boolean | `true` — ремонт успешно запущен в фоне |\n| `data.status` | string | Всегда `\"started\"` при успехе |\n\n## Пример ответа\n\n```json\n{\n  \"success\": true,\n  \"data\": { \"status\": \"started\" }\n}\n```\n\n## Пример ответа при ошибке\n\n409 — ремонт заблокирован (например, сервер помечен `preventWake=true`):\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"REPAIR_BLOCKED\",\n    \"message\": \"Repair blocked: server prevents wake\"\n  }\n}\n```\n\n## Ошибки\n\n| HTTP | Код | Описание |\n|------|-----|----------|\n| 401 | `MISSING_API_KEY` | Не передан заголовок `X-Api-Key` |\n| 401 | `INVALID_API_KEY` | Неверный или просроченный API-ключ |\n| 404 | `NOT_FOUND` | Сервер не существует, удалён или принадлежит другому API-ключу |\n| 409 | `REPAIR_BLOCKED` | Ремонт заблокирован: `preventWake=true` (биллинговая заморозка, административный блок) или сервер в особом состоянии |\n| 422 | `VM_MISSING` | У записи нет `externalId` — виртуальная машина не создана у провайдера. Удалите сервер и создайте новый |\n| 429 | `RATE_LIMITED` | Превышен общий лимит запросов платформы |\n\nПолный список общих ошибок API — [Ошибки](\u002Fdocs\u002Ferrors).\n\n## Известные особенности\n\n- **Почему serial console, а не SSH.** Когда агент не подключён, SSH через iptables BLACKHOLE-сервера недоступен. Serial console провайдера Bitrix Cloud минует файрвол на уровне гипервизора и позволяет внедрить SSH-ключ в уже работающую виртуальную машину, не перезагружая её.\n- **Идемпотентно.** Процедура выполняет полный цикл (стоп агента → скачивание свежего бинарника → чистая конфигурация → запуск) и безопасна для здорового сервера — навредить не может. Повторный вызов во время идущего ремонта просто вернёт 409\u002Fто же `started`, ничего не ломает.\n- **Режим сервера сохраняется.** OPEN-сервер остаётся OPEN (iptables не трогается), BLACKHOLE — BLACKHOLE.\n- **Как разблокировать `REPAIR_BLOCKED`.** Если сервер помечен `preventWake` (биллинговая заморозка, истёкший trial, админблок) — сначала устраните причину (пополните баланс, обновите тариф), потом повторите `\u002Frepair`.\n\n## Смотрите также\n\n- [Статус ремонта](.\u002Frepair-status.md) — `GET \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Frepair-status` — прогресс текущей операции.\n- [Обновить статус](.\u002Frefresh.md) — проверить, поправился ли `blackholeStatus` после ремонта.\n- [Получить сервер](\u002Fdocs\u002Finfra\u002Fservers\u002Fget) — проверить `blackholeStatus` и `status`.\n- [Перезагрузить сервер](.\u002Freboot.md) — альтернатива, если `repair` не помог.\n"]