83 行
5.2 KiB
Markdown
83 行
5.2 KiB
Markdown
---
|
||
schema: "hl-changelog/v2"
|
||
ticket: "frontend-fleet-batch3slot"
|
||
title: "多槽位（3 槽）派单提交 batchCreate 请求体缺顶层必填字段且丢槽，派单未创建"
|
||
consumer: "admin"
|
||
author: "wx(GIT)"
|
||
change_type: "前端缺陷"
|
||
backend_status: "not_required"
|
||
gateway_status: "not_required"
|
||
frontend_status: "not_required"
|
||
frontend_owner: ""
|
||
frontend_ref: ""
|
||
target_release: ""
|
||
verified_at: ""
|
||
status_note: "前端缺陷：3 槽位派单排车页点「下一步·发送给司机」，POST /admin/fleet/assignments/batch 请求体仅 {items:[2 个]}——缺 orderId/requirementId/startDate/endDate/holdMode/requestId 顶层必填字段，且 3 槽只发出 2 个 items（丢 1 槽）。后端返回 200 但未创建派单（看板 3 槽仍待派车）。2 槽位（26-6040）请求体完整、派单成功。后端无问题，待前端修复 3 槽位 batchCreate 请求体构造。"
|
||
updated_at: "2026-08-09"
|
||
base: "dev-v3"
|
||
generated: "2026-08-08T22:10:00+08:00"
|
||
---
|
||
|
||
# 多槽位（3 槽）派单提交 batchCreate 请求体缺顶层必填字段且丢槽，派单未创建
|
||
|
||
> 前端缺陷，待前端修复。后端接口与逻辑无问题。
|
||
|
||
## 关联 / 联系人
|
||
|
||
### 联系人
|
||
|
||
- **前端负责人**: @mmg
|
||
- **后端负责人**: @wx（已确认后端无问题）
|
||
|
||
## 现象（TEST 实测，2026-08-08）
|
||
|
||
订单 26-4254（id=2086056645539885057，跨月 8/30-9/1，18 人，用车需求 **SUV×1 + 商务车×1 + 大巴×1 共 3 槽位**）：
|
||
|
||
1. 排车页 3 个槽位逐日全部应用完成（页面显示「已完成 3/3 个最终方案槽位」，槽1 蒙A-E2E01 道尔吉 / 槽2 蒙A-E5555 阿木古愣 / 槽3 蒙C08E08 宝音德力格尔，各 3 天已确认）。
|
||
2. 勾上 8/30 接机「参与」（消除「至少一辆用车必须参与接机」警告）后，点底部「**下一步 · 发送给司机（3 辆）**」。
|
||
3. 抓包：`POST /admin/fleet/assignments/batch` 请求体为——
|
||
|
||
```json
|
||
{
|
||
"items": [
|
||
{"orderId":"2086056645539885057","vehicleId":"2085284111341023234","driverId":"2065272150012444674","assignmentGroupId":"2086057368872779778","serviceDates":["2026-08-30","2026-08-31","2026-09-01"]},
|
||
{"orderId":"2086056645539885057","vehicleId":"2064998142394183681","driverId":"2065272145633591298","assignmentGroupId":"2086057368876974082","serviceDates":["2026-08-30","2026-08-31","2026-09-01"]}
|
||
]
|
||
}
|
||
```
|
||
|
||
**两个错误**：
|
||
- **顶层缺必填字段**：无 `orderId` / `requirementId` / `startDate` / `endDate` / `holdMode` / `requestId`（这些字段只在每个 item 里出现了 orderId/assignmentGroupId，顶层全缺）。
|
||
- **丢槽**：3 个槽位只发出 **2 个 items**（丢了 1 个槽）。
|
||
|
||
4. 结果：后端返回 200，但**看板 3 槽位仍全部「待派车」**（activeAssignments=0），派单未创建。
|
||
|
||
## 对比（正常）
|
||
|
||
订单 26-6040（**2 槽位**）同样操作：batchCreate 请求体含完整顶层字段（orderId/requirementId/startDate/endDate/holdMode/requestId）+ 2 个 items，返回 200 且派单正常创建（holding）。
|
||
|
||
## 期望
|
||
|
||
3 槽位（多槽位）派单提交时，batchCreate 请求体应：
|
||
- 顶层携带完整必填字段：`orderId` / `requirementId` / `startDate` / `endDate` / `holdMode` / `requestId`；
|
||
- `items` 包含**全部槽位**（3 槽发 3 个 item），不丢槽；
|
||
- 每个 item 的 `fleetItemIndex` / `vehicleId` / `driverId` / `serviceDates` 与各槽位选择一致。
|
||
|
||
## 复现路径
|
||
|
||
派单看板 → 26-4254 → 派车派人 → 下一步 → 3 个槽位分别「统一选择车辆/司机」选好车+司机应用到槽位（3/3）→ 勾 8/30 接机「参与」→ 点「下一步 · 发送给司机（3 辆）」→ 抓 batchCreate 请求体。
|
||
|
||
## 备注
|
||
|
||
- 单槽位派单（AssignModal 单体 createAssignment，走 `useAssignFlow.handleSubmit`，payload 含完整字段）正常；问题在**多槽位排车页的批量提交**路径。
|
||
- 后端 batchCreate 接口对缺顶层字段的请求返回 200 而非 400 参数校验，建议后端顺带评估是否应 fail-fast（另案，不阻塞本前端修复）。
|
||
|
||
## 前端实证确认（2026-08-09 mmg，hl-admin v2.1）
|
||
|
||
该缺陷对应**已被替换的旧批量实现**，当前 v2.1 不满足复现条件，无需改动：
|
||
|
||
- **形态不符**：抓包的 `{items:[...]}`（缺顶层必填字段 + 3 槽发 2 个）是 `69847975 多车槽位原子批量派车` 的旧 items 形态；`7b99fe7d 支持逐日逐车派车方案`起已改为**逐日逐车 dailyPlan 模型**。
|
||
- **顶层字段齐全**：当前 `buildBatchAssignmentSubmission`（`useAssignFlow.js:375`）产出的 `data` 含完整顶层必填字段 `orderId/orderNo/requirementId/startDate/endDate/headcount/holdMode/fromEntry/requestId` + `dailyPlan`，**无 `items` 键**；测试 `useAssignFlow.spec.js:271` 明确断言 `data 不含 items`。
|
||
- **丢槽结构性不可能**：`validateDailyVehiclePlan`（`daily-vehicle-plan.js:518-527`）对每个服务日 × 每个槽位序号做笛卡尔积完整性校验，3 槽 × 3 天必须满 9 格，缺任一格在提交前即 `throw` 拦截（`服务日 X 缺少车辆槽位 N`），不会发出丢槽请求。
|
||
- **结论**：TEST 抓包来自旧前端版本。当前 v2.1 批量派单顶层字段齐全且丢槽被结构校验拦截，本单关闭为 not_required。
|