Вопрос владельца вскрыл дыру в деньгах. Списание за показы делает суточная
задача в 04:20 и берёт только кампании со статусом «крутится». Кампанию,
оставленную на паузе, она не видит никогда — значит показы, сделанные с
последнего списания, не оплачивались вовсе. До суток рекламы клиент получал
бесплатно, а Яндексу за неё платили мы.
Дыра открывалась только если после паузы не возобновить: при возобновлении
пропущенное списывается разницей.
Теперь «Пауза» после остановки рекламы спрашивает у Директа накопительное
число показов и списывает за них, и только затем возвращает остаток
заморозки. Лишнего обращения это не стоит — в Директ мы в этот момент и так
ходим останавливать рекламу.
Три случая разведены:
- обычный: списали, поставили паузу, вернули остаток;
- списание само закрыло кампанию по смете или сроку — уходит в «Показы
откручены» по ВЫХОДУ 1, паузу поверх не ставим, пятого выхода снятия
заморозки не появляется;
- не узнали число показов — рекламу остановили, но деньги НЕ отпускаем и
говорим об этом клиенту.
Сторож принят красным: до починки списание давало 0.00 вместо 300.00 рублей
за 2500 показов.
Найдена соседняя дыра того же рода при «Остановлено, нет денег» — там
слушатель работает изнутри денежной транзакции, и обращение к Яндексу внутри
неё держало бы замок строки на время сетевого запроса. Разобрано в отчёте,
чинить отдельным заходом.
Прогон: 387 сторожей блока рекламы, 177 денежных, статанализ 0, стиль чист.
Схема не менялась.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Восьми файлам рекламной папки поставлен откат после теста. Проверено остатком
в базе снаружи: папка оставляла 116 записей арендаторов, теперь 44. Папка
целиком зелёная - 351 из 351. Полный прогон после уборки: 4111 тестов,
4107 зелёных, 4 пропущено, ноль падений - значит на эту грязь никто не
опирался. Побочно прогон стал БЫСТРЕЕ: 12,9 минуты против 16,5.
Один файл намеренно оставлен как был, причина записана прямо в нём:
CampaignBannerEndpointsTest нарочно ловит отказ базы, а Postgres после отказа
внутри транзакции глушит все следующие команды. С откатом файл падает -
чинить надо сам тест, а не обёртку.
Датчик пришлось расшифровывать, и это стоит помнить. Числа сперва выходили
с минусами: файл, который базы не касается вовсе, «уносил» девять записей.
Прямым замером выяснилось, что КАЖДЫЙ прогон начинается с пересборки базы -
было 6 записей, стало 0 после теста про расписание. Значит разница «до/после»
при переборе файлов = оставил этот минус оставил предыдущий. Расшифровал
цепочкой, сумма сошлась со 116 ровно - на этом расшифровка и проверяется.
Поимённый расклад по файлам перенесён в промт.
Грабля на будущее, тоже в промте: uses() обязан стоять НИЖЕ подключений
классов. Подключение действует с места объявления и ниже, поэтому вызов
выше падает «класс не найден» - и падает сразу вся папка. Полное имя
с ведущей чертой не спасает: pint САМ превращает его в подключение внизу
и ломает работавший файл.
Остаток долга измерен и НЕ закрыт: ~20 файлов оставляют по одной-две записи,
среди них миграционные, которым откат может быть противопоказан по сути.
По всей папке Feature без отката 96 файлов из 580 - корень общий,
в app/tests/Pest.php строка RefreshDatabase закомментирована.
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>
Хвосты денег Д1-Д6 и робота Р-х1-Р-х6 из приёмочного листа v12.
Д1 цена, по которой заморожены деньги, записывается на кампанию. Пока поле было
пустым, списание читало глобальную цену — админ менял её, и клиент платил больше
обещанного при запуске.
Д2 суточное списание берёт кампанию под замком строки. Ключ идемпотентности зависит
от числа показов, поэтому два одновременных прогона получали разные ключи и списали
бы клиента дважды.
Д3 пауза, не дошедшая до Директа, больше не считается паузой: отказ 409, заморозка
остаётся. Раньше реклама крутилась дальше, портал показывал паузу, а деньги были уже
свободны. У возобновления поведение намеренно прежнее — иначе понадобилось бы пятое
место разморозки, а их ровно четыре. Там же убрана мина строгого сравнения рубильника.
Д4 не трогали — это вопрос владельца.
Д5 рубильник Директа держит и служебный канал робота: выдача задания и приём отчёта
ходили в живой кабинет мимо него.
Д6 проверка рубильника приведена к общему виду: YANDEX_DIRECT_ENABLED=0 давало строку,
которую строгое сравнение читало как включено.
Р-х1 настройки читаются из .env робота, а не каталога запуска.
Р-х2 файл-замок robot.lock: проход и поддержание входа больше не дерутся за профиль
браузера. Занят — уходим молча, задание остаётся в очереди. Брошенный замок
перехватывается через полчаса.
Р-х3 письмо-алярм честно говорит, залиты ли уже креативы в кабинет. Побочно вскрылось,
что тексты писем не проверялись ни одним тестом — транспорт вынесен в src/smtp.js.
Р-х4 тест-пустышка про рабочую папку заменён настоящим: запуск из чужого каталога без
явной папки. Проверено вырезанием.
Р-х6 пустое значение в окружении читается как значение по умолчанию, мусор даёт внятную
ошибку вместо тихого NaN.
Портал 293/293, робот 57/57. Денежных выходов снятия заморозки по-прежнему четыре.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Заморозка ставилась один раз при запуске на всю смету показов и не снималась
нигде — AdWalletService::release не вызывался ни одной строкой приложения.
Главное следствие было блокирующим: charge уменьшал balance_rub, но не трогал
frozen_rub, поэтому одни и те же рубли считались дважды. Свободный остаток
balance − frozen уходил в минус, а AdWalletGate::isSolvent вызывается сразу
после списания в ChargeCampaignSpendJob — клиент объявлялся неплатёжеспособным
после первого же суточного списания, и AdStopAll глушил все его кампании.
Кампания умерла бы после первого дня показов даже при полном кошельке.
Что сделано:
- charge уменьшает активный холд на списанную сумму, холд закрывается при нуле;
- release стал идемпотентным — отсутствие кошелька или холда больше не ошибка;
- выход 1 completed — CampaignImpressionCharger возвращает остаток резерва;
- выход 2 rejected — SyncCampaignModerationJob возвращает резерв целиком;
- выход 3 stopped_no_funds — PauseCampaignsOnAdStop снимает резерв;
- выход 4 paused — контроллер снимает резерв, resume морозит остаток сметы
до обращения к Директу и отдаёт 409 с понятным текстом при нехватке денег.
Удаление кампании выходом не является — destroy разрешён только для черновика,
а черновик ещё не заморожен.
Решение по паузе согласовано с владельцем 27.07.2026: на паузе деньги свободны.
Тесты: рекламный модуль 156/156. Переписан сценарий одного существующего теста
ChargeCampaignSpendJobTest — нехватку денег теперь создаёт резерв ВТОРОЙ
кампании, так как прежняя постановка опиралась на двойной счёт и стала
недостижимой; проверяемое требование сохранено.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Дмитрий