Ошибки и повторные попытки (retries)

Control Plane возвращает предсказуемые ошибки в JSON‑формате:

{
  "error": "...",
  "message": "...",
  "details": { ... }
}

Частые коды ответа

• 400 BadRequest — неверный payload, отсутствует обязательное поле, ошибка имени или формата;
• 401 Unauthorized — токен отсутствует, просрочен или неверен;
• 403 Forbidden — scope или permissions не позволяют выполнить операцию;
• 404 NotFound — ресурс не найден или скрыт политикой доступа;
• 409 Conflict / LimitExceeded — конфликт состояния или превышение лимита;
• 5xx — внутренняя ошибка платформы или сбой при работе с внутренними сервисами.

Отдельно полезно знать про OperationDisabled: такой ответ вы получите, если попытаетесь использовать публичный ручной start/stop/scale или передать start_immediately / initial_scale там, где текущий managed‑сценарий этого не допускает.

Как безопасно делать retries

Можно повторять

• GET‑запросы;
• временные сетевые ошибки;
• часть 5xx, если операция не дошла до сервера или не изменила состояние.

Нельзя слепо повторять

• destructive‑операции без проверки текущего состояния;
• POST create, если вы не убедились, что ресурс действительно не был создан с первого раза.

Хороший retry-паттерн

1. Выполнить write‑операцию.
2. Если ответ не пришёл или соединение оборвалось, сначала сделать GET / list.
3. Убедиться, что ресурс отсутствует или находится в ожидаемом состоянии.
4. Только после этого повторять write.

Учитывайте асинхронность

Создание и удаление ресурсов могут быть асинхронными. Поэтому после успешного ответа объект ещё не обязан мгновенно оказаться в финальном состоянии. Корректный сценарий — не паниковать, а читать состояние ресурса через GET.