Изменения API

API changelog — это отдельный срез журнала изменений для тех, кто пишет интеграции, CI/CD‑сценарии и внутренние сервисы поверх Control Plane API.

2026-03-21 — новые runtime‑поля writer autoscaler

В описании базы (GET /v2/tenants/:tenant/dbs/:db, GET /v2/dbs/:id) появились и/или стали значимыми новые поля, связанные с autoscale handoff.

Новые поля профиля и candidate generation

• current_profile
• target_profile
• candidate_profile
• candidate_worker_id
• candidate_writer_term

Новые поля состояния handoff

• scale_state
• freeze_new_checkouts
• lease_control_epoch
• autoscale_cooldown_until
• scale_phase_started_at
• scale_phase_deadline_at
• scale_failure_reason

Что это означает интегратору

Теперь API позволяет отличать:

• просто запущенную/остановленную базу;
• базу, которая уже меняет профиль;
• базу, где handoff завис на FREEZING, DRAINING, SWITCHING или ушёл в FAILED.

Поведенческий сдвиг

Это additive + behavioral изменение:

• формат базовых create/list/get маршрутов сохраняется;
• но интерпретация поля “scale” теперь должна учитывать не только current_scale/target_scale, но и профильную ось autoscaler.

Практическая рекомендация:

• для логики “запущен ли writer” продолжайте смотреть current_scale/target_scale;
• для логики “идёт ли handoff профиля” обязательно смотрите current_profile/target_profile/scale_state.

Что не изменилось

• ручные пользовательские start/stop/scale в managed‑контракте по‑прежнему отключены;
• start_immediately и initial_scale=1 не становятся рекомендуемым публичным путём;
• базовый workflow остаётся прежним: create tenant -> create db -> connect through Gateway.

Размерная модель

На стороне продукта и PAYG‑планов подготовлена линейка L1–L5, но активный runtime‑контракт autoscaler сейчас реализован для L1/L2.

Это значит:

• интеграции уже могут закладывать общую пользовательскую размерную шкалу L1–L5;
• но живой autoscale‑handoff нужно считать production‑активным именно для L1 <-> L2.