4.8 KiB
4.8 KiB
schema, ticket, title, consumer, change_type, author, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base, generated
| schema | ticket | title | consumer | change_type | author | backend_status | gateway_status | frontend_status | frontend_owner | frontend_ref | target_release | verified_at | status_note | updated_at | base | generated |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| hl-changelog/v2 | 5681 | 多槽位确认执行页逐日车费覆盖全程+HOLD 整组确认快照代际修复 | admin | 修改接口 | wx(GIT) | deployed | verified | not_required | 后端完成：PR #5690 已合并 dev-v3 并部署 TEST（12:52 滚动 DONE）。网关双探针 ALL PASS：自建 2 车需求订单 HOLD 派车→行级冻结代际→详情整组快照代际非空→两组逐日车费各覆盖全部出行日→司机确认→需求级整组确认 200 confirmed=true。前端无需配合（字段与守卫均沿用既有契约，此前是后端数据缺失）。 | 2026-08-08 | dev-v3 | 2026-08-08T13:00:00+08:00 |
多槽位确认执行页逐日车费覆盖全程+HOLD 整组确认快照代际修复
服务: hl-fleet-service PR: #5690 Issue: #5681 日期: 2026-08-08 影响: 🟢 缺陷修复，无契约结构变更（既有字段数据口径修复）。前端无需改代码。
背景
#5681（P1）wx 实测：订单 26-0703（4 人 2 车 2 司机，8/11-8/14）确认执行页：
- 逐日车费只显示 1 车 1 天（8/11）——应列出每个车每个出行日车费；
- 报「详情缺少整组确认快照，请刷新后重试」——多槽位无法确认执行。
根因（双缺陷）：
- 全程单行（service_date NULL）派车组聚合视图的
dailyVehicleFees/chargeableServiceDates/freeServiceDates由物理行 1:1 生成，serviceDateOf对全程行只取 startDate，逐日车费只产出 1 天； - #5400 重构时 dailyPlan 模式 HOLD 创建只退休旧代际标记、不再冻结新方案代际（items 模式两种模式都会冻结），导致 HOLD 单
dispatchPlanGeneration恒为 NULL，需求级整组确认的代际栅栏与前端整组快照守卫永远拿不到代际。
修复内容（内部，无接口/字段结构变化）
completeDailyPlanCreation：HOLD 逐日方案创建同样冻结方案代际（finalized=1 + generation，与 items 模式一致）；DAILY_V3 最终快照事件仍只在 DIRECT 创建时发布，HOLD 待最终确认后发布（#5400 意图不变）。aggregateGroupRows：全程行聚合视图逐日费用/收费日/免费日按 startDate..endDate 逐日展开。- 兼容：#5675 行程短链哨兵路径只服务存量无代际 HOLD 行，有代际行走真实代际校验，双向兼容；单车/逐日切片行为不变（回归测试钉住）。
变更接口
| 方法 | 路径 | 变更 |
|---|---|---|
| GET | /admin/fleet/board/orders/:orderId | activeAssignments[].dailyVehicleFees 全程行覆盖全部出行日；driverConfirmationSummary.dispatchPlanGeneration 对 HOLD 单正常返回 |
| POST | /admin/fleet/assignments/requirements/:requirementId/confirm | 多槽位 HOLD 整组确认可正常携带代际提交（修复前永远拿不到代际） |
验证证据
- 全量
mvn -pl hl-fleet-service -am verify：3283 Tests 0 失败；新增 4 回归（HOLD 冻结代际不发快照事件/DIRECT 对照发事件/全程行逐日车费展开 4 天/逐日切片不变）；spotless 通过。ReleaseEMixedBinaryHarnessTest（进程时序）与两个 Testcontainers 类（3306 端口并行争用）全量内环境性失败，单独重跑 23/23、2/2、10/10 全绿，与本改动无关。 - 部署 TEST：12:52 滚动 DONE。
- 网关端到端（自建 2 车需求订单 2085938395749515266，蒙C01E01+孟和/蒙A-S6666+苏和巴特，8/22-8/24）：HOLD 派车 → 行级 finalized=1+代际一致 → 详情整组快照代际非空 → 两组逐日车费各 3 天 → 两组司机确认 → 需求级整组确认 200 confirmed=true → DB 双行 assigned。单车对照（26-6179）逐日车费 3 天正常。
前端配合
无需配合。确认执行页的槽位切换、整组快照守卫（requirementId/version/sha/代际/groups）均为既有契约，此前是后端数据缺失导致守卫不通过；修复后原链路自然恢复。
前端实证确认（2026-08-08 mmg，hl-admin）
逐行核实确认 not_required 属实，零代码改动：整组快照守卫在 src/views/fleet/board/composables/useAssignFlow.js:166-169 与 :518-531，前端直读 driverConfirmationSummary.dispatchPlanGeneration、空则抛「详情缺少整组确认快照，请刷新后重试」——正是本单后端修复的守卫，前端是正确消费方，此前因 HOLD 单代际恒 NULL 不通过，后端补冻结代际后原链路自然恢复；逐日车费前端仅逐日渲染 activeAssignments[].dailyVehicleFees，后端全程行按 startDate..endDate 展开后自动正确。前端无任何针对该缺陷的特判或 workaround 需拆除。