[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"docs-infra\u002Fdeploy\u002Flock":3,"docs-tabs-infra\u002Fdeploy\u002Flock":6},{"content":4,"lastmod":5},"\n## Снять зависший лок\n\n`DELETE \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Flock`\n\nПринудительно снимает зависший лок операции на сервере. Используйте, когда [`\u002Fexec`](.\u002Fexec.md) или [`\u002Fdeploy`](.\u002Fdeploy.md) оборвались со стороны клиента (потеряно соединение, локальный таймаут), но на сервере всё ещё активен лок и последующие вызовы возвращают `EXEC_BUSY`. Эндпоинт всегда возвращает 200: если лок был — снят и в ответе `released: true`, если его не было — вернётся `released: false` (тоже успех).\n\n> **Используйте осторожно.** Снятие лока активной операции может привести к непредсказуемому состоянию сервера — одновременно запущенные `\u002Fexec` и `\u002Fdeploy` могут конкурировать за файлы и systemd-юниты.\n\n## Параметры\n\n| Параметр | В | Тип | Обяз. | Описание |\n|----------|---|-----|:-----:|----------|\n| `id` | path | string (UUID) | да | ID сервера |\n\nТело запроса пустое.\n\n## Примеры\n\n### curl — личный ключ\n\n```bash\ncurl -X DELETE -H \"X-Api-Key: YOUR_API_KEY\" \\\n  https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002FSERVER_ID\u002Flock\n```\n\n### curl — OAuth-приложение\n\n```bash\ncurl -X DELETE -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\u002Flock\n```\n\n### JavaScript — личный ключ\n\n```javascript\nconst res = await fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002F${serverId}\u002Flock`,\n  {\n    method: 'DELETE',\n    headers: { 'X-Api-Key': 'YOUR_API_KEY' },\n  }\n)\nconst { data } = await res.json()\n\nif (data.released) {\n  console.log(`Снят лок ${data.operation}, держался ${data.ageMs}ms, до истечения было ${data.expiresInMs}ms`)\n} else {\n  console.log(data.message)  \u002F\u002F \"No active lock on this server\"\n}\n```\n\n### JavaScript — OAuth-приложение\n\n```javascript\nawait fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.tech\u002Fv1\u002Finfra\u002Fservers\u002F${serverId}\u002Flock`,\n  {\n    method: 'DELETE',\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.released` | boolean | `true` — был активный лок, и он снят. `false` — лок отсутствовал |\n| `data.operation` | string | Тип снятой операции: `\"exec\"` или `\"deploy\"`. Присутствует только при `released: true` |\n| `data.ageMs` | number | Сколько миллисекунд лок был активен. Присутствует только при `released: true` |\n| `data.expiresInMs` | number | Через сколько миллисекунд лок истёк бы сам. Присутствует только при `released: true` |\n| `data.message` | string | Сообщение `\"No active lock on this server\"`. Присутствует только при `released: false` |\n\n## Пример ответа\n\nЛок был — снят:\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"released\": true,\n    \"operation\": \"deploy\",\n    \"ageMs\": 320000,\n    \"expiresInMs\": 580000\n  }\n}\n```\n\nЛока не было:\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"released\": false,\n    \"message\": \"No active lock on this server\"\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- **Один лок на сервер.** Защита от гонок между `\u002Fexec` и `\u002Fdeploy` — они делят один общий лок. Невозможно заблокировать отдельную команду.\n- **Автосброс при нормальном завершении.** Успех или ошибка `\u002Fexec`\u002F`\u002Fdeploy` снимают лок сами. `DELETE \u002Flock` нужен только когда клиент оборвал соединение до завершения или таймаут агента прошёл без отправки финального события.\n- **TTL лока — автоистечение без вызова.** `\u002Fexec` ставит лок на `timeout + 30 + 60` секунд. `\u002Fdeploy` — на 15 минут. Даже без `DELETE \u002Flock` зависший лок истечёт сам.\n- **`released: false` — это успех**, не ошибка. Эндпоинт не возвращает 404 при отсутствии лока, потому что идея в том, чтобы «гарантировать, что лока нет». Клиенту не важно, был он или не был.\n- **Работает в любом режиме сервера.** В отличие от большинства Deploy API эндпоинтов, `DELETE \u002Flock` не требует BLACKHOLE — лок держится в памяти платформы, не зависит от агента.\n\n## Смотрите также\n\n- [Выполнить команду](.\u002Fexec.md) — основной источник `EXEC_BUSY`.\n- [Полный деплой](.\u002Fdeploy.md) — долгая операция, лок на 15 минут.\n- [Метрики туннеля](.\u002Fmetrics.md) — `available: true` + `httpConnections: 0` показывает, идёт ли реальная работа.\n","2026-06-23",{}]