hl-api-changelog/changelogs-v2/2026-08/06_5613_派单恢复取消500修复：DAILY_V3快照拓扑按最终方案实际覆盖槽位-修改接口-管理后台.md

schema, ticket, title, consumer, author, change_type, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base, generated

schema	ticket	title	consumer	author	change_type	backend_status	gateway_status	frontend_status	frontend_owner	frontend_ref	target_release	verified_at	status_note	updated_at	base	generated
hl-changelog/v2	5613	派单恢复取消500修复：DAILY_V3快照拓扑按最终方案实际覆盖槽位	admin	wx	修改接口	deployed	verified	not_required					后端完成：PR #5623 合并 dev-v3（c10aea0f0）并部署 TEST（hl-fleet-service + hl-order-service-v3）；网关实测派单 2085286010924527618 取消后 restore-cancel 返回 200 assignmentStatus=assigned，DAILY_V3 快照 revision 1 同步成功，order 侧 requirement DONE、planFleetItemIndexes=[1]、planTopologySize=4。	2026-08-07	dev-v3	2026-08-06T19:45:00+08:00

派单恢复取消500修复：DAILY_V3快照拓扑按最终方案实际覆盖槽位

服务端已部署 TEST 并网关验证；管理后台契约不变，无强制前端改动。

关联 / 联系人

链接

• Issue: #5613
• PR: #5623
• Merge commit: c10aea0f0

联系人

• 后端负责人: @wx

变更接口

方法	路径	来源	变更
POST	/admin/fleet/assignments/<assignmentId>/restore-cancel	AssignmentController（fleet）	语义修复：多槽需求只保留部分槽位时恢复取消不再 500（修复前 IllegalStateException: DAILY_V3 snapshot invalid: daily rows do not cover declared topology，事务回滚、状态保持 canceled）；恢复成功返回 assignmentStatus=assigned、车辆/司机占用回 busy。接口出入参不变

内部契约（同步放宽，随本单一起部署）：POST /v3/internal/order/vehicle-assignment/callback（DAILY_V3 配车快照回写）的 planFleetItemIndexes 校验由「必须等于需求声明全槽」放宽为「需求全槽的非空子集」。即车务最终方案只保留部分槽位（未保留槽位按「车务最终实派方案未保留该车辆槽位」取消）时，快照拓扑只含实际保留槽位，订单侧正常接受并回写 requirement 快照摘要。

契约影响文件

• hl-fleet-service/src/main/java/com/hulalv/fleet/assignment/snapshot/service/DailyVehicleAssignmentSnapshotFactory.java（快照拓扑按最终方案实际覆盖槽位收窄；每保留槽×每服务日一行、至少一个用车 cell 等 fail-closed 校验不变）
• hl-order-service-v3/src/main/java/com/hulalv/order/requirement/service/DailyVehicleAssignmentSnapshotService.java（validateAgainstRequirement：ASSIGNED 快照 planFleetItemIndexes 允许为需求全槽的非空子集；拓扑完整性仍由 isDailySnapshotValid 强制）

根因与修复说明

• 根因：需求声明多槽（如 suv+mpv × 4 天 = 拓扑 8），但车务最终方案允许只保留部分槽位——未保留槽位的 unassigned 占位按「车务最终实派方案未保留该车辆槽位」取消且 dispatch_plan_finalized=0，不参与当前最终代。恢复取消（restore-cancel）在事务 BEFORE_COMMIT 触发 DAILY_V3 快照生成时，快照工厂仍按 requirement.fleet 全槽拓扑校验当前 final 行（4 行 ≠ 8）→ IllegalStateException → 500，恢复事务回滚，取消后无法恢复。
• 修复：① fleet 快照工厂的拓扑以当前最终方案实际覆盖的槽位为准（planFleetItemIndexes/planTopologySize/dailyAssignments 一致），未保留槽位不再要求行覆盖；② order 侧回调校验同步接受需求全槽的非空子集。
• 影响范围：仅影响「多槽需求 + 部分槽位最终方案」场景（修复前该场景任何快照生成都会失败，不止恢复取消）；全槽最终方案与 NO_VEHICLE_REQUIRED 行为不变。

前端/调用方动作

1. 无强制改动：restore-cancel 接口与出入参不变；修复前该场景直接 500，现在正常返回。
2. 展示留意：多槽需求只派部分槽位时，订单侧快照摘要 assignmentPlanFleetItemIndexes 现在会正常回写为保留槽子集（修复前该场景快照从不成功、需求卡 PROCESSING）。若管理后台/订单详情按需求全槽渲染车辆槽位，可结合快照拓扑判断哪些槽位实际派车、哪些未保留。

验证证据

• 定向测试：fleet DailyVehicleAssignmentSnapshotFactoryTest 11/11（+2：部分槽位快照成功 / 保留槽缺日仍 fail-closed）；order DailyVehicleAssignmentSnapshotServiceTest 14/14（+2：子集 APPLIED / 超集拒绝）
• 回归：AssignmentServiceTest 376、DailyVehicleSnapshotGenerationServiceTest 15、RequirementServiceTest 198、InternalRequirementControllerTest 14、VehicleAssignmentSnapshotContractRedTest 7、E2eVehicleAssignmentFinalizeServiceTest 46 全绿
• fleet 全量 mvn -pl hl-fleet-service -am verify（含 spotless）BUILD SUCCESS；order-v3 verify 的 11 个失败类经与 #5610 worktree 基线报告逐类对比完全一致（Testcontainers/MyBatis 环境问题），非本单引入
• 网关验证（TEST，经 api.test.1814.love:9443）：派单 2085286010924527618（需求 2 槽 × 08-2023、最终方案只保留 mpv 槽）取消后 POST /admin/fleet/assignments/2085286010924527618/restore-cancel → 200 assignmentStatus=assigned，4 行恢复 assigned 且 canceled_at 清空；DAILY_V3 快照 outbox revision 1 投递 SUCCESS；order 侧 requirement 回 DONE、planFleetItemIndexes=[1]、planTopologySize=4、usedVehicleDayCount=4，order_vehicle_assignment 4 行（mpv 槽 08-2023，车辆/司机/费用齐全）