Если план простоял в WAITING_DECISION дольше waiting-decision-grace-minutes
(по умолчанию 30) после своего начала и решения по нему так и нет — перестаём
ждать подтверждение: снимаем активную выдачу, двигаем якорь цепочки на этот
план и выдаём следующий. Статус плана не меняется (остаётся WAITING_DECISION,
не ACCEPTED) — это молчаливое продолжение цепочки, а не приёмка. Запоздалое
решение по такому плану просто пишется на attempt и не откатывает ушедшую
вперёд цепочку.
Раньше вся будущая цепочка планов материализовалась в planned_plan как
PLANNED-строки, а отдельный воркер пересчёта (RebuildPlanScheduleUseCase +
PlanRecalculationJob) держал её в актуальном состоянии и гасил выпавшие планы
в SUPERSEDED/EXPIRED. Это плодило вложенные планы, гонки пересчёта и мусор в БД.
Новая модель: в БД живёт только выданное (история навсегда), будущее — проекция,
вычисляемая по запросу из ЗРВ. Перекрывать (supersede) и протухать (expire)
больше нечего.
Бэкенд:
- Удалены TrackedPlan (entity/source/status + repo) и PlanRecalculationJob
(entity/repo/service/worker) — материализация и воркер пересчёта больше не нужны.
- Удалён RebuildPlanScheduleUseCase; будущее строит новый PlanProjectionService
поверх PlanCalculationService.
- PlanQueryService отдаёт проекцию (выданное из БД + будущее на лету).
- Новый флоу реакции на смену параметров станции: StationParamsChangedConsumer +
HandleStationParamsChangedUseCase (срочный перевыпуск через planning_state).
- Новые консьюмеры обратной связи исполнения: LayinFailedConsumer,
PlanNotAcceptedConsumer (+ DTO PlanExecutionFeedbackMessage,
StationParamsChangedMessage).
- PlannedPlanStatus: убраны мёртвые SUPERSEDED/EXPIRED; статусы выровнены под
жизненный цикл выдачи/закладки.
Миграции (ddl-auto: validate):
- V7 drop tracked_plan
- V8 drop plan_recalculation_job
- V9 planning_state: поля срочного перевыпуска
- V10 снять unique-ограничение бизнес-ключа planned_plan
- V11 удалить легаси PLANNED-строки (материализованное будущее)
- V12 удалить легаси SUPERSEDED/EXPIRED и столбец superseded_by_plan_id
Тесты: удалены JobRerunFlowTest и RebuildPlanScheduleUseCaseTest; добавлены
PlanProjectionServiceTest, PlanQueryServiceTest, IssueDuePlanWorkerOnDemandTest,
HandleStationParamsChangedUseCaseTest, VisibilityPayloadParserTest. Скорректированы
PlanIssueAndDecisionFlowTest, PlanCalculationServiceTest, VisibilityFlowTest и др.
V11/V12 необратимы — перед миграцией на проде снять дамп planned_plan.
Воспроизводит форму с экрана Reflexio (раннее окно, большой провал
видимости, далёкий кластер) и проверяет, что цепочка перекрывает провал
одним длинным планом и доходит до далёкого кластера без разрыва.
Старт следующего плана всегда выбирается строго внутри текущего плана
(нахлёст по времени), а раньше был fallback на ближайший более поздний
старт, который мог дать разрыв. Если ни одна ЗРВ не начинается внутри
текущего плана — цепочка обрывается, но разрыв между планами не создаётся.
calculatePlansAfter тоже стартует хвост строго внутри принятого плана.
Инвариант цепочки в тестах усилен проверкой строгого нахлёста; добавлен
тест на провал видимости.
Цепочка планов теперь строит соседние планы со строго возрастающими
стартом и концом, поэтому ни один план не может лежать целиком внутри
другого. Нахлёст «на одну ЗРВ» считается по времени, а не по плоскому
индексу кандидата — это убирает вложенность при нескольких станциях,
видящих один пролёт одновременно (кейс Emissio).
Подчистка устаревших PLANNED-планов при rebuild переведена на условие
end_time > now, чтобы гасить и уже стартовавшие вложенные планы.
Classify Ordinis classifier transport failures and empty responses as unavailable, keep stale platform cache when possible, and expose Prometheus metrics/alerting for the outage signal.
состояние окон видимости, расписания планов, попыток выдачи и job’ов перенесено в БД;
план и попытка выдачи разделены на разные сущности;
Kafka-события теперь двигают persisted state/jobs, а не локальную память pod’а;
BPMN createSatelliteMission теперь отвечает только за одну попытку выдачи плана;
обновление слотов после принятия плана вынесено в отдельный BPMN-процесс;
workers используют DB claim/lock model и безопасны для нескольких pod’ов;
тестовый ручной API вынесен в отдельный disabled-by-default controller
Дмитрий Соловьев