320e48ac61
一些检查失败了
changelog-filename-gate / validate (push) Failing after 2s
纯后端复核闭环修复,无接口契约变化;前端 dispatchPlanGeneration 透传回 confirm、 staleFinalizedPlan/finalizedByFleet 系后端派生状态,零改动自动受益。 frontend_status 补 frontend_owner/ref=db1f3507 + 前端复核说明。
55 行
4.2 KiB
Markdown
55 行
4.2 KiB
Markdown
---
|
||
schema: "hl-changelog/v2"
|
||
ticket: "5910"
|
||
title: "修复改订单人数后车务复核确认无法闭环——复核confirm按全需求行判定满派并重新盖章"
|
||
consumer: "admin"
|
||
change_type: "修复"
|
||
author: "wx(GIT)"
|
||
backend_status: "deployed"
|
||
gateway_status: "not_required"
|
||
frontend_status: "not_required"
|
||
frontend_owner: "mmg"
|
||
frontend_ref: "db1f3507"
|
||
target_release: ""
|
||
verified_at: "2026-08-12"
|
||
status_note: "后端已修复并部署测试服，API 实测闭环通过。改订单人数换版打回待派车后，车务核对沿用原车/司机，对派车点「确认执行」复核即可：复核时按整个需求判定满派并重新盖章（归属→当前需求）发 finalPlan，订单正确回到「配车完成」。此前复核后订单永久卡「处理中」的死锁已解除。前端 2026-08-12 复核 not_required：无接口契约变化、零新字段消费；dispatchPlanGeneration 系详情快照透传回 confirm 乐观锁（useAssignFlow.js:136-148/449-462），后端重盖章后下发新值前端直读最新；staleFinalizedPlan/finalizedByFleet 系后端派生状态（BoardSlotSummary.vue:189-194），复核闭环后由后端翻正，前端展示逻辑不变自动受益，无需联调改动。"
|
||
updated_at: "2026-08-12"
|
||
base: "dev-v3"
|
||
---
|
||
|
||
# 修复：改订单人数后车务复核确认无法闭环——复核confirm按全需求行判定满派并重新盖章（#5910）
|
||
|
||
> **服务**: hl-fleet-service
|
||
> **PR**: #5911（已合并 dev-v3 并部署测试服）
|
||
> **日期**: 2026-08-12
|
||
> **背景**: 承接 #5851（换版即作废定稿）+#5899（守卫防自动重新盖章）。改订单人数换版打回待派车后，车务复核 confirm 无法把订单推回「配车完成」。
|
||
|
||
## 修复内容（对前端透明，无接口契约变化）
|
||
|
||
**根因**：`AssignmentService.revalidateAssignedAfterBaselineChange`（复核 confirm 走的分支）两处叠加：
|
||
|
||
1. 用**单组行** `isRequirementFinalizedTopologyRows(groupRows,...)` 对**整个需求**拓扑，多车订单单组行数 ≠ 槽位×日期，必 false → 永不发 finalPlan。
|
||
2. 复核 confirm 全程不调 `markDispatchPlanFinalized` 重新盖章，`plan_finalized_requirement_id` 永留旧需求 → #5899 守卫 `hasStaleFinalizedPlanRows` 永命中 → 即便拓扑齐全也不发 finalPlan。
|
||
|
||
旁证死锁：`batchCreate` 重新提交原方案被 605014 拒、`change` 改派被 605029 强制真换车/司机，车务「确认沿用原方案」无出口。
|
||
|
||
**修复**：复核 confirm 改用**需求下全部行** `isRequirementFullyAssignedRows` 判满派（内部已含陈旧定稿降级 + 载客量校验，部分派单/缺车/容量不足返回 false，防 #5824 误标 DONE），满派时**先 `markDispatchPlanGeneration` 重新盖章（归属→当前需求）再发 finalPlan**。车务逐组复核，最后一组复核完即闭环，订单回「配车完成」，车/司机沿用原方案不用换。
|
||
|
||
## 行为变化
|
||
|
||
| 场景 | 旧 | 新 |
|
||
|---|---|---|
|
||
| 多车订单改人数后复核 confirm | ❌ 永久卡「处理中」，不盖章不发 finalPlan，无 API 可救 | ✅ 复核即整需求重新盖章发 finalPlan，订单回「配车完成」 |
|
||
| 部分派单/缺车/容量不足复核 | ✅ 不盖章不发 finalPlan | ✅ 不变（防 #5824 误标 DONE） |
|
||
| 单车订单改人数后复核 | ❌ 同样卡死 | ✅ 正常闭环 |
|
||
|
||
## 验证证据（测试服 API 实测，订单 2086270141158346754，2 组多车）
|
||
|
||
换版作废后（两组 `assigned` + `finalized=0` + `generation=NULL` + 归属旧 v3，需求 PROCESSING，订单「配车 处理中」）：
|
||
|
||
- 车务对第一组复核 confirm → 触发**整需求重新盖章**：两组 `dispatch_plan_finalized=1`、新 `generation=345816481176621056`、归属全部 → 当前 v4
|
||
- 发 finalPlan：订单「配车」`PROCESSING 处理中` → `DONE 已完成`，需求 `PROCESSING` → `DONE`
|
||
- 车务看板：`dispatchPlanGeneration=345816481176621056` 一致、两组「已派车」、执行全确认
|
||
|
||
单测：新增多车满派重新盖章+发finalPlan、部分派单不盖章不发finalPlan（防 #5824 回归）、单车回归 3 例；调整容量不足/行程中换版 2 例断言。AssignmentServiceTest 480 + ArchTest 13 + spotless 全绿，反向验证有效。前端无改动，无需联调。
|