Прод-баг: 5 из 9 работающих проектов на бою показывали жёлтое «Готовим
к запуску», хотя заказ у поставщика реально стоял и лиды шли. У трёх
клиентов; самый старый врал 13 дней.
Причина. Связь проекта с заказом хранится в двух местах: три legacy-колонки
supplier_b{1,2,3}_project_id и pivot project_supplier_links. Статус читался
ТОЛЬКО из колонок. При этом ночной SyncSupplierProjectsJob — единственный,
кто в режиме batch реально заводит заказ, — пишет ТОЛЬКО в pivot и колонок
не касается вообще. Колонки заполняет лишь SyncSupplierProjectJob и только
если заказ УЖЕ существует в момент запуска; при создании проекта заказа ещё
нет, он появится в 18:00. Итог: колонки остаются пустыми навсегда, пока
клиент сам не дёрнет проект — пауза, снятие с паузы, «Синхронизировать»
или правка настроек.
Правка. resolvedSupplierProjects() возвращает объединение pivot и трёх
legacy-колонок без дублей. Legacy читаем дальше: handleBatch пишет колонку
без pivot-строки, такие проекты терять нельзя. getSupplierLinks() берёт
площадку из самой строки заказа. Списку и карточке добавлен eager-load
supplierProjects — иначе N+1 на каждую карточку.
Данные править не нужно: связки в pivot уже лежат, пятёрка чинится сама
в момент выката.
Тесты: 9 новых, 5 из них падали до правки. Полный прогон 3569 тестов:
3563 зелёных, 2 падения — чужие, в ClientTg\InputLengthFixTest, красные
и без этой правки.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Дмитрий
f01f9fa289