#Статус восстановления

GET /v1/infra/servers/:id/repair-status

Возвращает прогресс фонового восстановления туннеля, запущенного через `POST /repair`. Используется для периодического опроса: клиент видит текущий шаг (wake / serial_console / ssh_install / connect / …), финальный статус (running / done / failed) и в случае ошибки — поле error. Завершённые записи автоматически очищаются через 10 минут.

#Параметры

Параметр В Тип Обяз. Описание
id path string (UUID) да ID сервера

#Примеры

#curl — личный ключ

Terminal 
curl -H "X-Api-Key: YOUR_API_KEY" \
  https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/repair-status

#curl — OAuth-приложение

Terminal 
curl -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/repair-status

#JavaScript — личный ключ

javascript 
// Цикл опроса прогресса
while (true) {
  const res = await fetch(
    `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}/repair-status`,
    { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
  )
  const { data } = await res.json()

  if (data.status === 'idle') { console.log('Ремонт не запущен'); break }
  if (data.status === 'done')  { console.log(`Готово, шаг: ${data.step}`); break }
  if (data.status === 'failed'){ console.error(`Ошибка на шаге ${data.step}: ${data.error}`); break }

  console.log(`Шаг: ${data.step}`)
  await new Promise(r => setTimeout(r, 10000))
}

#JavaScript — OAuth-приложение

javascript 
const res = await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}/repair-status`,
  {
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
    },
  }
)

#Поля ответа

Поле Тип Описание
success boolean Всегда true при успехе
data.status string idle (ремонт не запускался или очищен по таймауту), running (идёт), done (успешно), failed (провалился)
data.step string Текущий/последний шаг: wake, serial_console, ssh_install, connect, iptables, cleanup, done
data.agentVersion string | null Версия установленного агента (заполняется на шаге ssh_install)
data.wasSlept boolean Был ли сервер в sleeping на момент запуска ремонта (тогда после done возвращается в sleeping)
data.error string Текст ошибки, если status: "failed"
data.startedAt number Timestamp старта ремонта (миллисекунды Unix)

Для status: "idle" возвращается только поле status, остальные поля отсутствуют.

#Пример ответа

Ремонт не запускался:

JSON 
{
  "success": true,
  "data": {
    "status": "idle"
  }
}

Ремонт идёт, завершён шаг установки агента:

JSON 
{
  "success": true,
  "data": {
    "status": "running",
    "step": "connect",
    "agentVersion": "1.2.3",
    "wasSlept": false,
    "startedAt": 1745312400000
  }
}

Ремонт провалился:

JSON 
{
  "success": true,
  "data": {
    "status": "failed",
    "step": "ssh_install",
    "agentVersion": null,
    "wasSlept": false,
    "error": "SSH connection refused",
    "startedAt": 1745312400000
  }
}

#Пример ответа при ошибке

404 — сервер не существует:

JSON 
{
  "success": false,
  "error": {
    "code": "NOT_FOUND",
    "message": "Server not found"
  }
}

#Ошибки

HTTP Код Описание
401 MISSING_API_KEY Не передан заголовок X-Api-Key
401 INVALID_API_KEY Неверный или просроченный API-ключ
404 NOT_FOUND Сервер не существует, удалён или принадлежит другому API-ключу
429 RATE_LIMIT_EXCEEDED Превышен общий лимит запросов платформы

Полный список общих ошибок API — Ошибки.

#Известные особенности

  • Порядок выполнения шагов: wake (если сервер в sleeping) → serial_console (впрыск SSH-ключа через serial console Yandex Cloud) → ssh_install (SSH-подключение и переустановка агента: скачивание бинаря, запись конфигурации, запуск сервиса) → connect (ожидание подключения агента к Gateway) → iptables (восстановление файрвола для BLACKHOLE) → cleanup (возвращение в sleeping, если сервер был спящим) → done.
  • TTL завершённых записей — 10 минут. После этого повторный опрос вернёт idle. Если нужно подтвердить результат после TTL, смотрите на blackholeStatus в `GET /v1/infra/servers/:id` — если он CONNECTED, ремонт сработал.
  • Одновременный ремонт невозможен — на уровне сервиса стоит in-memory замок repairingServers. Повторный `POST /repair` на сервере с уже идущим ремонтом корректно обрабатывается: второй вызов не запускает новую процедуру.

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