7.1 KiB
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
| 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| hl-changelog/v2 | 8142 | 车务派单看板: 行程用车与接送机需求并存时，接送机需求整行从列表消失——已修复，同一订单现按需求维度出多条记录 | admin | wx(GIT) | 修复 | deployed | not_required | not_required | 本条不改变 GET /admin/fleet/board/orders 的任何响应字段名、类型或嵌套结构，变的是记录的产出规则：修复前该端点在「一单同时有活跃 TRAVEL 需求与活跃 TRANSFER 需求」时只产出其中一条需求的记录，另一条整行不出现（且出现的那条还可能挂着另一类的 requirementRemark 与派车行）；修复后每条活跃用车需求各出一条记录。gateway_status=not_required：零新增路由，端点既有。frontend_status=not_required：hl-ui（origin/v2.1）的看板列表与卡片视图早已用 requirementId 作 row-key（src/views/fleet/board/utils/boardSummary.js:9-14，resolveBoardRecordKey，注释原文「看板已按当前有效用车需求聚合；列表身份必须锚定 requirementId，历史响应缺失时才回退原记录/订单 ID」），同一订单多条记录不会撞 key，无需前端改动——这是查证结论不是推断，若后续发现有按 orderId 去重的调用点，以那处为准另发订正。backend_status=deployed：hl-fleet-service 与 hl-order-service-v3 均已滚动到测试服 78d0aad3d（分别 2026-09-23 07:38:54 / 07:40:25），并在测试服活体上完成改前/改后对跑取证，读数见正文第四节。 mmg 2026-09-23 复核: grep 实证 resolveBoardRecordKey 锚定 requirementId(boardSummary.js:9-14)多单不撞 key;virtualPending 为既有字段,index.vue/display.js/AssignModal 均已消费;域内唯一按 orderId 建的 Map 是未读数查找表(unreadByOrderId),多单同值无冲突——not_required 成立。 | 2026-09-23 | dev-v3 |
车务派单看板: 行程用车与接送机需求并存时，接送机需求整行从列表消失
存放目录: 二期（order-v3）→
changelogs-v2/2026-09/服务: hl-fleet-service（看板候选与聚合）+ hl-order-service-v3（需求身份供给）+ hl-common PR: #8211 Issue: #8142 日期: 2026-09-23 影响范围:
GET /admin/fleet/board/orders（车务派单看板列表 / 待派分面）
⚠️ 关键变化
-
同一订单现在可能出现多条记录，每条活跃用车需求各一条。 字段名、类型、嵌套结构零变化，变的是记录的产出规则。 如果你的代码里有「一个 orderId 对应一条记录」这个隐含假设（按 orderId 去重、按 orderId 建 Map、用 orderId 当列表 key），它现在不成立了。
hl-ui当前实现不受影响——看板列表与卡片视图已用requirementId作 row-key（src/views/fleet/board/utils/boardSummary.js:9-14）。 -
requirementId现在是列表记录的身份键，orderId不是。 唯一性口径是(orderId, requirementId)组合，requirementId恒非 null。 -
requirementRemark/dailyAssignments/requiredVehicles现在保证属于本记录自己的那条需求。 修复前存在反向错配：TRANSFER 需求的记录上挂着 TRAVEL 需求的requirementRemark，派车行也只显示了其中一部分。 -
「接送机还没派车」的虚拟待派卡现在会出现在待派分面里（
virtualPending: true、dailyAssignments: []、assignmentStatus: "unassigned"、assignmentGroupId: null）。修复前这类需求在列表侧完全不可见，车务无从发现「这单的接送机还没派车」。
一、变更接口清单
| 方法 | 路径 | 变更性质 |
|---|---|---|
| GET | /admin/fleet/board/orders |
响应字段结构不变，记录产出规则变更（一单一条 → 一需求一条） |
本条不属「新增接口 / 修改接口」：无新增或删除的请求参数，无新增、删除或改名的响应字段，无新增错误码。
二、失败形态（供你判断历史数据与截图）
修复前有两种形态，都静默——接口返 200、code=200、无任何错误码或警告字段：
形态甲 · 整批不出现：两类需求并存时只产出一条记录，另一条整行没有。
实测：某广口径查询 .data.total 修复前 22、修复后 25，多出的 3 条恰好一单一条落在三个订单上。
形态乙 · 反向错配：产出的那条记录 requirementId 是 A 需求的，而 requirementRemark 是 B 需求的，dailyAssignments 只含 A 的一部分派车行。
实测订单 HL20260919104049371：修复前该条记录 requirementId=7330964160969957（TRANSFER）却带着 TRAVEL 的备注、只有 1 条日行；修复后备注是自己的、日行 2 条（与库中该需求的活派车行集合逐条相等）。
⇒ 修复前的看板截图与导出数据不可作为历史对账依据，涉及两类需求并存的订单需重新拉取。
三、边界：有一类记录按设计仍然不出现
用车需求处于 DONE/CANCELED 等非待派状态、且零条活派车行时，看板不为它造虚拟待派卡，只打一条 warn 日志。
这属于数据不一致的兜底分支（BoardCandidateSource.java:383-397，判据 isAwaitingDispatch = PENDING || PROCESSING），不是本次修复的残留。
⇒ 若你看到某单「库里有这条需求、看板上没有」，先看该需求的 status：非 PENDING/PROCESSING 且零派车行时，这是预期行为。
四、后端已验证的读数（测试服活体，部署 commit 78d0aad3d）
| 验证项 | 读数 |
|---|---|
| 虚拟待派卡可见 | 某 TRANSFER 需求记录数 0 → 1，该单 .data.total 1 → 2；virtualPending=true、dailyAssignments=[] 与库一致 |
| 两类派车行各自完整 | TRAVEL 与 TRANSFER 两条需求的日行 assignmentGroupId 集合，与库中各自的活派车行集合逐条相等 |
| 单类订单零回归 | TRAVEL-only 与 TRANSFER-only 两单，响应递归展平后各 243 / 205 个叶路径，各只有 1 个键变化且都是随日期自然漂移的 daysUntilDeparture（恰好 −1）；剔除该键后改前/改后 sha256 完全相等 |
| 待派分面未被打穿 | 广口径 ?statuses=unassigned 返 total=133；fleet 日志中 fail-open 分支关键词 0 命中（同窗口任意 board 日志行 21 条，证明日志在写） |
| 记录唯一性 | 8 份响应逐份核 (orderId, requirementId) 对唯一、requirementId 非 null 全绿 |
五、你需要做的
- 无需改动即可继续工作；若你的代码按 orderId 去重或建 Map，改为按
requirementId（或(orderId, requirementId)）。 - 渲染时优先用
requirementId作列表 key。 - 展示「这单还有没有没派的车」时，把
virtualPending: true的记录算进去——它就是「有需求、还没派车」这一状态的载体。