Прогон рекламной папки оставлял в базе 44 записи. Теперь ноль, папка целиком
зелёная — 351 из 351. Полная tests/Feature: 3282 теста, 0 падений, и после неё
в базе не остаётся НИЧЕГО, кроме справочников, которые кладутся при сборке.
Два места прошлая смена считала неизлечимыми — оба вылечились, потому что
диагноз был не перепроверен:
1. CampaignBannerEndpointsTest оставлял 24 записи, больше половины всей грязи.
Он нарочно ловит отказ базы, а после отказа внутри транзакции Postgres
глушит все следующие команды. Лечение — ловить отказ в ОТДЕЛЬНОЙ точке
сохранения: DB::transaction внутри уже открытой ставит savepoint и
откатывает только его. Приёмка вырезанием: убрал уникальный ключ в
миграции — тест покраснел ровно там, где должен; вернул — зелёный.
2. AdWalletUnderRealRoleTest. В промте: «откат противопоказан, он ходит
настоящей ролью базы». Оказалось — не противопоказан, смена роли идёт по
ТОМУ ЖЕ соединению и незакоммиченные записи видны. Тут была реальная
опасность, что откат обезвредит самого сторожа, поэтому вырезание делал
отдельно: убрал у службы установку контекста клиента — оба теста
покраснели. Значит сторож сторожит по-прежнему.
Журнал вебхука оставлял 4 строки: он пишется ВТОРЫМ соединением к базе, куда
обычный откат не дотягивается. Двум файлам добавлена общая связка соединений
(SharesSupplierPdo) — папка вебхука теперь оставляет ноль.
Прежняя оценка исправлена. В промте стояло «~20 файлов оставляют по одной-две
записи». На деле после уборки восьми главных грязь оставляли ДВА файла из всей
папки: 2 и 3 записи, сумма сошлась с наблюдаемыми 5 ровно. «Нет отката» и
«гадит в базу» — разные вещи: папка Autopodbor, где без отката 16 файлов, не
оставляет ни одной записи. Мерить надо остатком, а не поиском по тексту.
Боевой код не тронут: git diff по app/app/ пуст после каждой правки.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Найдено при разборе шва с веткой телеграм-рекламы: обе ветки правили один денежный
файл с разных сторон, и сравнение вскрыло поломку у нас.
Снятие заморозки не удаляет строку брони, а метит её снятой. На броне висит запрет
двух одинаковых записей по четвёрке тенант-канал-тип-источник. Повторная заморозка
той же кампании заводила строку заново и падала на дубле ключа.
По-человечески: клиент ставил кампанию на паузу и больше не мог её включить. Та же
дорога на новом пути отказ модерации - Исправить - отправить заново.
Почему 391 зелёный тест этого не видел. Есть два теста, и каждый честен по
отдельности: первый морозит и снимает, второй берёт кампанию, которую никогда
не морозили, и морозит. Последовательность снять и заморозить снова не проверял
никто - шов между двумя половинками остался голым.
Проверено прогоном, не рассуждением: база ответила дублирующееся значение ключа
нарушает ограничение уникальности ad_wallet_holds по ключу yandex campaign 1.
Починка взята у ветки телеграм-рекламы, которая наткнулась на то же самое: не
заводить бронь заново, а оживлять снятую. Оба сторожа написаны до починки и
проверены вырезанием - без неё падают, с ней проходят.
Реклама 393 из 393 при 1249 проверках, было 391. Админка и кошелёк 23 из 23.
На боевой не выкатывалось, никуда не отправлялось, рубильник Директа выключен.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Дмитрий