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

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

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

## Параметры

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

## Примеры

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

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

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

```bash
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_LIMITED` | Превышен общий лимит запросов платформы |

Полный список общих ошибок API — [Ошибки](/docs/errors).

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

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

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

- [Восстановить туннель](./repair.md)
- [Получить сервер](/docs/infra/servers/get)
- [Обновить статус](./refresh.md)