Дмитрий Соловьев
c76a823dbc
Раньше вся будущая цепочка планов материализовалась в 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.
config-repo
Файлы в этом подпроекте предназначены для spring-cloud-config-server.
Ожидаемый сценарий:
- этот каталог хранится в GitLab-репозитории с конфигами
spring-cloud-config-serverчитает его черезCONFIG_GIT_URI- сервисы запрашивают конфиги по имени
spring.application.name
Для tle-monitoring-service используются файлы:
tle-monitoring-service.yaml
Пример запроса к Config Server:
GET /tle-monitoring-service/local
Архитектурные договоренности:
pcp-request-serviceявляется единственным owner request/grid-домена.pcp.services.requestдолжен использоваться как основной runtime endpoint для requests/cells/grid.pcp.services.earth-gridсохранен только как legacy alias и должен резолвиться вpcp.services.request.- lifecycle booked slots должен идти Kafka-first; legacy HTTP
/api/slots/booking/processне считается рабочим основным путем. pcp.services.adminуказывает наpcp-srpring-boot-admin-server; сервисы PCP должны регистрироваться в нем через Spring Boot Admin client.