lekss361/gendesign

Fork 0

fix(ptica): у пользователя не может быть двух дефолтных профилей весов (#2464) #2976

Merged

bot-backend merged 1 commit from fix/2464-default-profile-unique into main

2026-08-20 12:23:29 +00:00

bot-backend commented

2026-08-20 11:59:17 +00:00

Collaborator

Пункт эпика #2464: weight_profiles.py:99.

Два дефекта одного места

create_profile/update_profile делают «снять is_default у всех → поставить новому» двумя отдельными операторами. Между ними инвариант нарушен: при одновременных запросах у пользователя может оказаться два профиля с is_default=TRUE.

А читающий _SELECT_DEFAULT брал LIMIT 1 без ORDER BY — выбор молча перескакивал между ними от запроса к запросу.

Два рубежа, а не один


миграция 190	частичный уникальный индекс `(user_id) WHERE is_default` — два дефолта невозможны на уровне БД
`ORDER BY id ASC`	детерминированный выбор, если индекс когда-нибудь снимут

Соседние запросы этого же файла тай-брейк по id уже имели — приводим к ним.

Индекс не мешает штатной переустановке дефолта: порядок операторов в коде уже правильный (сначала снять у всех, потом поставить), поэтому в момент проверки дефолтов ноль. Проверено отдельным тестом.

Безопасность миграции

На проде нарушений нет: у admin один дефолт, у __system__ ноль, ни одного пользователя с двумя. Таблица в 4 строки — индексируется мгновенно. lock_timeout проставлен по #2752.

Тесты

Поведение на живом Postgres: вторая установка дефолта отвергается базой.

Плюс фальсификация — без индекса два дефолта вставляются молча. Без неё зелёный тест неотличим от «оно и так не вставлялось».

Плюс два контроля: переустановка дефолта работает; разные пользователи сохраняют свои дефолты.

Про размещение теста

Проверку ORDER BY вынес в tests/services/site_finder, а не внёс в skip_allowlist: живой БД она не требует, и пропускаться вместе с DB-тестами ей незачем. Против origin/main краснеет, показывая запрос без тай-брейка.

Прогоны

без БД   648 passed   rc=0
с БД       5 passed   rc=0

Пункт эпика #2464: `weight_profiles.py:99`. ## Два дефекта одного места `create_profile`/`update_profile` делают «снять `is_default` у всех → поставить новому» **двумя отдельными операторами**. Между ними инвариант нарушен: при одновременных запросах у пользователя может оказаться два профиля с `is_default=TRUE`. А читающий `_SELECT_DEFAULT` брал `LIMIT 1` **без `ORDER BY`** — выбор молча перескакивал между ними от запроса к запросу. ## Два рубежа, а не один | | | |---|---| | миграция 190 | частичный уникальный индекс `(user_id) WHERE is_default` — два дефолта невозможны на уровне БД | | `ORDER BY id ASC` | детерминированный выбор, если индекс когда-нибудь снимут | Соседние запросы этого же файла тай-брейк по `id` уже имели — приводим к ним. Индекс не мешает штатной переустановке дефолта: порядок операторов в коде уже правильный (сначала снять у всех, потом поставить), поэтому в момент проверки дефолтов ноль. Проверено отдельным тестом. ## Безопасность миграции На проде нарушений нет: у `admin` один дефолт, у `__system__` ноль, ни одного пользователя с двумя. Таблица в 4 строки — индексируется мгновенно. `lock_timeout` проставлен по #2752. ## Тесты Поведение на живом Postgres: вторая установка дефолта отвергается базой. Плюс **фальсификация** — без индекса два дефолта вставляются молча. Без неё зелёный тест неотличим от «оно и так не вставлялось». Плюс два контроля: переустановка дефолта работает; разные пользователи сохраняют свои дефолты. ## Про размещение теста Проверку `ORDER BY` вынес в `tests/services/site_finder`, а **не** внёс в `skip_allowlist`: живой БД она не требует, и пропускаться вместе с DB-тестами ей незачем. Против `origin/main` краснеет, показывая запрос без тай-брейка. ## Прогоны ``` без БД 648 passed rc=0 с БД 5 passed rc=0 ```

bot-backend added 1 commit 2026-08-20 11:59:18 +00:00

fix(ptica): у пользователя не может быть двух дефолтных профилей весов (#2464 )

CI Trade-In / changes (pull_request) Successful in 8s

Details

CI / changes (pull_request) Successful in 9s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Successful in 2m26s

Details

CI / backend-tests (pull_request) Successful in 17m14s

Details

afa648b21f

create_profile/update_profile делают «снять is_default у всех → поставить новому»
двумя отдельными операторами. Между ними инвариант нарушен, и при одновременных
запросах у пользователя может оказаться ДВА профиля с is_default=TRUE. А читающий
_SELECT_DEFAULT брал LIMIT 1 БЕЗ ORDER BY — выбор молча перескакивал между ними от
запроса к запросу.

Два рубежа, а не один:

миграция 190 — частичный уникальный индекс (user_id) WHERE is_default: два
дефолта становятся невозможными на уровне БД;
ORDER BY id — детерминированный выбор, если индекс когда-нибудь снимут.
Соседние запросы этого файла тай-брейк по id уже имеют.

Индекс не мешает штатной переустановке дефолта: порядок операторов в коде уже
правильный (сначала снять у всех, потом поставить), поэтому в момент проверки
дефолтов ноль. Это отдельно проверено тестом.

Безопасность миграции: на проде нарушений нет — у admin один дефолт, у __system__
ноль, ни одного пользователя с двумя. Таблица в 4 строки, индексируется мгновенно.
lock_timeout проставлен по #2752.

Тест проверяет ПОВЕДЕНИЕ на живом Postgres: вторая установка дефолта отвергается
базой. Плюс фальсификация — без индекса два дефолта вставляются молча; без неё
зелёный тест неотличим от «оно и так не вставлялось». Плюс два контроля:
переустановка дефолта работает, разные пользователи сохраняют свои.

Тест про ORDER BY вынесен в tests/services/site_finder, а НЕ внесён в
skip_allowlist: живой БД он не требует, и пропускаться вместе с DB-тестами ему
незачем. Против origin/main он краснеет, показывая запрос без тай-брейка.

Прогоны: без БД — 648 passed rc=0; с БД — 5 passed rc=0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

bot-backend merged commit 131b83c2fe into main

2026-08-20 12:23:29 +00:00

bot-backend commented

2026-08-20 12:39:33 +00:00

Author

Collaborator

Проверено на проде

Деплой 131b83c2 зелёный, код в живом контейнере (не по статусу джобы):

gendesign-backend-1 /app/app/services/site_finder/weight_profiles.py:112
     ORDER BY id ASC

Миграция 190 применилась — индекс на проде есть:

user_weight_profiles_one_default
    CREATE UNIQUE INDEX ... ON public.user_weight_profiles USING btree (user_id) WHERE is_default

Индекс не декорация — фальсифицирован на живых данных (вставка в SAVEPOINT с откатом):

профили: [('admin','admin',True), ('__system__','Эконом',False),
          ('__system__','Комфорт',False), ('__system__','Бизнес',False)]
вставка второго дефолта ОТБИТА: duplicate key value violates unique
    constraint "user_weight_profiles_one_default"
следов пробы: 0

Честно о масштабе

Дубликатов на проде не было (0 пользователей с >1 дефолтом, всего 4 профиля). Защита предупредительная, а не исправительная — она не чинит существующую порчу, а закрывает возможность её создать. ORDER BY id ASC при этом делает выбор победителя детерминированным и сейчас: без него порядок был на усмотрение планировщика.

Побочно замечено: user_weight_profiles_default_idx (неуникальный, (user_id) WHERE is_default = true) теперь полностью перекрыт новым уникальным — избыточная запись на каждой вставке. Отдельным пунктом, здесь не трогаю.

## Проверено на проде Деплой `131b83c2` зелёный, код в живом контейнере (не по статусу джобы): ``` gendesign-backend-1 /app/app/services/site_finder/weight_profiles.py:112 ORDER BY id ASC ``` Миграция 190 применилась — индекс на проде есть: ``` user_weight_profiles_one_default CREATE UNIQUE INDEX ... ON public.user_weight_profiles USING btree (user_id) WHERE is_default ``` **Индекс не декорация — фальсифицирован на живых данных** (вставка в SAVEPOINT с откатом): ``` профили: [('admin','admin',True), ('__system__','Эконом',False), ('__system__','Комфорт',False), ('__system__','Бизнес',False)] вставка второго дефолта ОТБИТА: duplicate key value violates unique constraint "user_weight_profiles_one_default" следов пробы: 0 ``` ## Честно о масштабе Дубликатов на проде **не было** (0 пользователей с >1 дефолтом, всего 4 профиля). Защита предупредительная, а не исправительная — она не чинит существующую порчу, а закрывает возможность её создать. `ORDER BY id ASC` при этом делает выбор победителя детерминированным *и сейчас*: без него порядок был на усмотрение планировщика. Побочно замечено: `user_weight_profiles_default_idx` (неуникальный, `(user_id) WHERE is_default = true`) теперь полностью перекрыт новым уникальным — избыточная запись на каждой вставке. Отдельным пунктом, здесь не трогаю.

bot-backend referenced this pull request

2026-08-20 12:40:52 +00:00

EPIC: exhaustive line-by-line аудит backend ПТИЦЫ (2026-07-07) — 89 подтверждённых находок #2464