From e7410b4d95b51fbd5681336a7954f0ed525f1bc6 Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Wed, 12 Aug 2026 11:56:41 +0800 Subject: [PATCH] =?UTF-8?q?chore:=205899=20=E6=94=B9=E8=AE=A2=E5=8D=95?= =?UTF-8?q?=E4=BA=BA=E6=95=B0=E5=90=8E=E8=BD=A6=E5=8A=A1=E6=9C=AA=E9=87=8D?= =?UTF-8?q?=E8=B5=B0=E9=85=8D=E8=BD=A6=E2=80=94=E2=80=94=E6=8D=A2=E7=89=88?= =?UTF-8?q?=E5=90=8E=E8=87=AA=E5=8A=A8=E9=87=8D=E6=96=B0=E7=9B=96=E7=AB=A0?= =?UTF-8?q?=E6=8A=B5=E6=B6=88=E4=BD=9C=E5=BA=9F=E5=AE=9A=E7=A8=BF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Sonnet 4.6 --- ...订单人数后车务未重走配车-修复-管理后台.md | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 changelogs-v2/2026-08/12_5899_改订单人数后车务未重走配车-修复-管理后台.md diff --git a/changelogs-v2/2026-08/12_5899_改订单人数后车务未重走配车-修复-管理后台.md b/changelogs-v2/2026-08/12_5899_改订单人数后车务未重走配车-修复-管理后台.md new file mode 100644 index 0000000..fb334fd --- /dev/null +++ b/changelogs-v2/2026-08/12_5899_改订单人数后车务未重走配车-修复-管理后台.md @@ -0,0 +1,58 @@ +--- +schema: "hl-changelog/v2" +ticket: "5899" +title: "修复改订单人数后车务未重走配车——换版后自动重新盖章抵消作废定稿" +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 实测通过。修改订单人数/车型等（服务日期窗不变）的换版后，车务看板正确回到「待派车」，订单侧停留在「待配」，不再被自动拉回「配车完成」；车务重新确认后订单正常推进。改行程天数/改出发日期不受影响。" +updated_at: "2026-08-12" +base: "dev-v3" +--- + +# 修复：改订单人数后车务未重走配车——换版后自动重新盖章抵消作废定稿（#5899） + +> **服务**: hl-fleet-service +> **PR**: #5903（已合并 dev-v3 并部署测试服） +> **日期**: 2026-08-12 +> **背景**: 订单修改人数后，订单侧短暂显示「待配」又立刻回到「配车已完成」，车务侧看板没有重走配车流程，仍保持「配车完成」，待派车 tab 无此单。 + +--- + +## 修复内容（对前端透明，无接口契约变化） + +**根因**：`AssignmentService.expandFromRequirementInTransaction` 换版时同事务内先后执行两个互相矛盾的动作： + +1. `invalidateDispatchPlanForMigratedRows`（#5851）换版平移后作废定稿——清 `dispatch_plan_finalized`/`dispatch_plan_generation`，意图让车务重走配车。 +2. `publishDailySnapshotIfComplete`（#5810）紧接着发现「行都 assigned 且无 finalized」→ 走 `markDispatchPlanGeneration` **自动重新盖章**（finalized=1、归属=新需求）→ 发 `DailyVehicleSnapshotChangedEvent.finalPlan` → 订单被拉回 `VEHICLE_DONE`。 + +**修复**：`publishDailySnapshotIfComplete` 检测到归属旧需求的陈旧定稿行时（`hasStaleFinalizedPlanRows` 命中）直接返回，不自动盖章/发 finalPlan。车务 confirm 时归属被重新盖成当前需求，守卫自然放行，闭环保留。 + +**影响范围**：仅服务日期窗不变的换版（改人数/车型/座位）。改行程天数/改出发日期时日期校验本就返回 false，不误触发。 + +## 行为变化 + +| 场景 | 旧 | 新 | +|---|---|---| +| 改人数后（服务窗不变） | ❌ 看板停留「配车完成」，订单误拉回 DONE，车务没机会重走配车 | ✅ 看板回到「待派车」，订单停留「待配」，等车务重新确认 | +| 车务重新确认 | ✅ 正常盖章并推进订单 | ✅ 不变（守卫放行） | +| 改行程天数/改出发日期 | ✅ 正常 | ✅ 不变 | + +## 验证证据（测试服 API 实测，订单 2086270141158346754） + +修改订单人数（10→11）后实测： + +- 需求换版 v4，`status=PENDING`（不再自动拉回 DONE） +- fleet 派单行 `dispatch_plan_finalized=0`、`plan_finalized_requirement_id` 保留旧 v3（归属证据） +- 车务看板卡片：`finalizedByFleet=False`、`staleFinalizedPlan=True` → 「待派车」tab +- 订单侧 VEHICLE：`PROCESSING 待配 | 配车待配`（不再误显示「配车已完成」） + +后端 PR #5903 已合并 dev-v3 并部署测试服，fleet-service 健康。前端无改动，无需联调。 +