From 0dfcfd1fc9fa7bc8fc38b788a0f05a8dd40cee0c Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Wed, 12 Aug 2026 14:35:06 +0800 Subject: [PATCH] =?UTF-8?q?docs(changelog):=20=E6=94=B9=E8=AE=A2=E5=8D=95?= =?UTF-8?q?=E4=BA=BA=E6=95=B0=E5=A4=8D=E6=A0=B8=E7=A1=AE=E8=AE=A4=E6=97=A0?= =?UTF-8?q?=E6=B3=95=E9=97=AD=E7=8E=AF=E4=BF=AE=E5=A4=8D(#5910)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...订单人数复核确认无法闭环-修复-管理后台.md | 54 +++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 changelogs-v2/2026-08/12_5910_改订单人数复核确认无法闭环-修复-管理后台.md diff --git a/changelogs-v2/2026-08/12_5910_改订单人数复核确认无法闭环-修复-管理后台.md b/changelogs-v2/2026-08/12_5910_改订单人数复核确认无法闭环-修复-管理后台.md new file mode 100644 index 0000000..a2b0ec3 --- /dev/null +++ b/changelogs-v2/2026-08/12_5910_改订单人数复核确认无法闭环-修复-管理后台.md @@ -0,0 +1,54 @@ +--- +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: "" +frontend_ref: "" +target_release: "" +verified_at: "" +status_note: "后端已修复并部署测试服，API 实测闭环通过。改订单人数换版打回待派车后，车务核对沿用原车/司机，对派车点「确认执行」复核即可：复核时按整个需求判定满派并重新盖章（归属→当前需求）发 finalPlan，订单正确回到「配车完成」。此前复核后订单永久卡「处理中」的死锁已解除。" +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 全绿，反向验证有效。前端无改动，无需联调。