Гейт репозитория поймал упущение: блокирующий DDL без lock_timeout (#2752).
Без него ALTER TABLE встаёт в очередь за чужой сессией и уводит за собой запросы
приложения. Добавлен `SET LOCAL lock_timeout = '5s'` первой строкой после BEGIN.
Пять секунд — про ОЖИДАНИЕ блокировки, не про работу: таблица 297 строк, сам DDL
мгновенный. Не дождались — миграция падает, а не подвешивает прод.
Заодно переписан разбор миграции в тесте-репетиции. Он дважды подвёл на мне же:
1) пропускал куски, начинающиеся с «--» → терялся DELETE, репетиция падала
на ADD CONSTRAINT;
2) резал SQL по «;», встреченной ВНУТРИ текста комментария.
Теперь комментарии снимаются ДО разбиения на выражения — оба класса закрыты.
Прогон: tests/sql/test_2464_land_reservation_dedup.py — 6 passed rc=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ВНИМАНИЕ: миграция 189 УДАЛЯЕТ строки на проде (см. «Что удаляется»).
_UPSERT_NO_ACT_SQL заканчивается ON CONFLICT DO NOTHING, а единственный подходящий
констрейнт — uq_land_reservation_cad_act UNIQUE (cad_num, act_number) с обычной
NULL-семантикой. В Postgres NULL != NULL, поэтому у записей БЕЗ номера акта
конфликт не наступает никогда: DO NOTHING не срабатывает, каждый недельный прогон
вставляет копию. То есть ON CONFLICT здесь был декорацией.
Замер прода 20.08.2026:
строк всего 297
из них act_number IS NULL 297 (все)
групп (cad_num, doc_url) с дублями 27
максимум копий одной записи 11
лишних строк 270 (91% таблицы)
Что удаляется: копии сверх первой (минимальный id) в каждой группе. Это порождение
бага, а не пользовательские данные: таблица — кэш OCR-разбора PDF с сайта,
пересобираемый прогоном таски. Проверено, что ключ подходит: ни у одного cad_num
нет более одного doc_url (max = 1), дубли внутри групп — точные копии.
Прецеденты NULLS NOT DISTINCT в репо: м.110, м.125, м.140, м.158. Prod = PG16.4.
Документация приведена к реальности. Docstring обещал python-дедуп по
(cad_num, doc_url) и «двухшаговый UPSERT ниже» — ни того, ни другого в коде не
было. Комментарий у варианта B был честнее, но его оценка «rare, data audit OK»
не подтвердилась: 91% таблицы. Отложенный там вариант (уникальный индекс на NULL)
и реализован этой миграцией.
Тест репетирует миграцию на ВРЕМЕННОЙ копии, засеянной как прод (11 копий одной
записи + соседний участок): исполняет РЕАЛЬНЫЕ выражения из файла, проверяет
12 строк → 2 и что повторная вставка стала no-op. Плюс фальсификация: со СТАРЫМ
констрейнтом дубль обязан появиться — без неё зелёный тест неотличим от «оно и
так работало». Плюс два контроля: записи С номером акта дедуплицировались и
раньше, разные участки не схлопываются.
Первая версия репетиции упала на ADD CONSTRAINT — я разбивал миграцию по «;» и
молча выбрасывал куски, начинающиеся с комментария, вместе с DELETE. Это ровно
то, что репетиция и должна ловить; разбор исправлен.
Прогоны: tests/sql (живой Postgres) 6 passed rc=0; -k "izyatie or reservation"
76 passed rc=0. Шесть nodeid в skip_allowlist.txt — нужен Postgres, в CI идут.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
main принёс PR #2751 (ruff-шаг в ci-tradein.yml/backend-tests) параллельно с
fetch-depth: 0 из этой ветки в том же job'е — не противоречат друг другу,
слились автоматически.
Единственное ручное разрешение — _manifest_applied.txt (modify/delete):
main дописал файл, ветка его удаляет. Разрешение — удаление, это и есть
предмет PR: гейт номеров миграций берёт эталон из git (origin/main), а не
из ручного манифеста, который отставал и по построению не мог покраснеть
(#2683, живой инцидент 15.08 — коллизия 264_ между двумя независимыми ветками).
Review-разбор ветки fix/tradein-uptime-honest-green:
1. [HIGH] Прод-симптом `HEAD gendsgn.ru/health -> 405` обслуживает Site
Finder (Caddyfile:60 `handle /health { reverse_proxy backend:8000 }`),
а предыдущий коммит правил только tradein-mvp/backend, чей /health наружу
не проксируется вообще. Добавлен @app.head("/health") в backend/app/main.py
рядом с существующим @app.get — эмпирически подтверждено (uv run pytest):
HEAD было 405, стало 200. tradein-mvp фикс не откачен (безвреден, годится
для будущего internal-caller), но обвязан комментарием, что реальный
прод-путь чинится не там.
2. [LOW] Response(status_code=200) без media_type отдавал HEAD без
Content-Type, тогда как GET отдаёт application/json — расходится с
заявленным в комментарии RFC 9110 §9.3.2. Добавлен media_type в обоих
бэкендах; Content-Length сознательно не подгоняем под байты GET-ответа
(payload header field, RFC разрешает опускать для HEAD) — не дублируем
сборку payload ради байт-в-байт соответствия.
Тесты: test_health_head_ok_no_body добавлен в backend/tests/test_health.py
(Site Finder) — RED-check (git stash app/main.py) воспроизводит прод-баг
1:1: assert 405 == 200. tradein-mvp/backend/tests/test_health_endpoint.py
дополнен проверкой Content-Type. uv run pytest — все зелёные.
Лоадер ЕЭСК писал степень загрузки из колонки E как
`load_index = COALESCE(load_index, CAST(:load_pct AS text))`.
load_index — категориальная: 'open'|'limited'|'closed'|NULL
(data/sql/180_connection_capacity.sql:35), её заполняет
rosseti_wfs_loader._map_load_index.
Число строкой в этой колонке ломает обе стороны: фронтовый classifyLoadIndex
отбрасывает всё вне перечисления в null («неизвестно»), а
power_summary.by_load_index — словарь по значению, то есть получил бы бакет
с именем вида "41.0" рядом с open/limited/closed.
Сегодня не стреляло только потому, что load_index заполнен у всех строк
(open 2741 / limited 346 / closed 329, NULL 0 — замер верификации 13.08,
подтверждён вторым прогоном скептика), и COALESCE не проваливался. Первая же
строка с пустым индексом положила бы туда число.
Колонку E больше не читаем: места под процент в power_supply_centers нет —
load_index категориальный, current_load_mva в мегавольт-амперах.
_pct_share_to_percent оставлен с тестами, но в докстроке теперь прямо
написано, что продакшен-вызывающих у него НЕТ и при каких условиях он снова
понадобится — чтобы «код есть, эффекта нет» не выглядел работающим.
Старый тест фиксировал ровно отменяемое поведение (`first["load_pct"] == 41.0`)
— заменён на проверку, что ни SQL, ни параметры загрузку не несут. Проверять
пришлось исполняемый текст, а не прозу: слово load_index осталось в поясняющем
комментарии, и наивная проверка на подстроку падала на своём же объяснении.
Тесты двусторонние: против лоадера из main падает ровно новый.
Хунк форматирования — не мой: pre-commit ruff v0.7.4 против 0.15.12 (#2864).
Refs #2464
Конфликт modify/delete по tradein-mvp/backend/data/sql/_manifest_applied.txt
разрешён удалением — удаление и есть предмет PR. За трое суток в main дописали
три имени (240/250/251); дописывать их некуда: файла больше нет, а гейт
tests/test_migration_numbering.py берёт эталон применённого из origin/main.
Проверено, что удаление ничего не оставляет без потребителя: манифест не *.sql,
цикл миграций в deploy-tradein.yml и bootstrap схемы в ci-tradein.yml берут
glob '*.sql', новый scripts/check-migration-lock-timeout.py — тоже.
Замер дрейфа на 27e199e3: 216 имён в манифесте против 232 файлов, отставание
16 (было 15 на 07.08). Старый гейт на этом дереве: 4 passed.
# Conflicts:
# tradein-mvp/backend/data/sql/_manifest_applied.txt
_manifest_applied.txt по построению не мог покраснеть. Тест считал «новым»
любой файл, которого нет в списке, а новые файлы от списка освобождены
(докстринг test_manifest_covers_all_but_new_files: «НЕ требует, чтобы новый
файл уже был в manifest»). Забытое имя и новая миграция PR для гейта — одно и
то же, поэтому дрейф был не пропуском проверки, а её штатным исключением.
Замер на main 2026-08-07: 15 имён не дописано, все четыре теста зелёные —
через сутки после того, как #2692 догнал список руками.
Список при этом был лишь копией того, что git и так знает: deploy-tradein.yml
применяет КАЖДЫЙ data/sql/*.sql из main под ON_ERROR_STOP, то есть «файл
доехал до main» и есть «имя закреплено на проде». Ведём эталон в git — и
дрейфовать становится нечему.
Кросс-ветковая дыра закрыта тем же ходом: номер нового файла сверяется с
ПОЛНЫМ origin/main, а не с рабочим деревом, поэтому коллизия с миграцией,
смерженной после ветвления, находится. Проверено на живом PR #2754
(234_trade_in_estimates_retain_until против 234_scrape_runs_ban_kind_unknown
из main): старый гейт зелёный, новый красный.
Удаление/переименование применённой миграции сверяется с ТОЧКОЙ ВЕТВЛЕНИЯ, а
не с origin/main: иначе ветка недельной давности краснела бы за чужие
миграции. Проверено — ветка от 2026-07-30 при +43 миграциях в main зелёная.
CI: checkout переведён на fetch-depth 0 + отдельный fetch main. Этот Forgejo
не публикует refs/pull/N/merge (1620 */head, ноль */merge), а на depth=1 нет
ни origin/main, ни общего предка — без этого гейту не с чем сверять, и он
намеренно красный, а не тихо пропущенный.
Контракт сведён к одной формулировке — докстринг test_migration_numbering.py;
шапка манифеста, правило 3, хвост манифеста и рецепт из .claude/rules
удалены или заменены ссылкой. Заодно исправлен сам рецепт: `git ls-tree` без
`-r` печатает каталог, а не файлы.
Refs #2683
PII scrub wired to BOTH channels (before_send AND before_send_transaction) in app/main.py and app/workers/celery_app.py.
Before: Celery had no before_send at all, and before_send_transaction was URL-only while glitchtip_traces_sample_rate defaults to 0.05 - the Starlette integration puts request.data on transaction scope exactly as on error scope, so lead bodies leaked through the transaction channel.
Keys: full MERA set (client_name/client_phone/client_email/phone/email/name) plus company/message from PilotRequestInput.
VAT label: 'NDS (parking)' -> 'NDS (parking + commercial)' in DOCX/HTML exporters - financial.py computes VAT over parking AND non-residential.
