wx/hl-api-changelog
1
0
派生 0
代码 工单 合并请求 Actions 软件包 项目 版本发布 百科 动态
hl-api-changelog/changelogs-v2/2026-08/10_5782_派车确认后车控状态卡10分钟修复-修复-管理后台.md
API Changelog Bot 719031462f
一些检查失败了
changelog-filename-gate / validate (push) Failing after 2s
详情
docs(changelog): #5782 补端到端实测数据(fence 352ms/回配 36 秒/时区正确) 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-10 12:29:03 +08:00

5.0 KiB
原始文件 Blame 文件历史

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, generated
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 generated
hl-changelog/v2 5782 派车确认后订单侧「车控处理中」不再卡 10 分钟；配车完成时间不再早 8 小时 admin wx(GIT) 修复 deployed not_required not_required mmg 2026-08-10 接口契约零变化，前端无需改动。两点行为变化前端可感知：①车控状态回配不再需要等 10 分钟（端到端实测 36 秒，fence 占用由 10 分钟降至 352 毫秒）；②assignmentCompletedAt 等时间字段口径修正（此前早 8 小时）。测试服 12:26 已用真实 API 走完整确认链路验证通过。 2026-08-10 dev-v3 2026-08-10T12:40:00+08:00

车务/订单: 派车确认后订单侧「车控处理中」不再卡 10 分钟；配车完成时间不再早 8 小时

服务: hl-fleet-service (8087/8187) + hl-order-service-v3 (8086/8186) PR: #5783 Issue: #5782 日期: 2026-08-10 影响范围: 管理后台订单详情「用车安排」状态回配时效；配车完成/提交/调价时间字段展示口径

一、背景

车务派单看板已显示「已派车」，但定制师侧订单详情「用车安排」仍显示 车控处理中、流程条停在 配车·处理中，约 10 分钟后才变「已回配」。每次派车/改派确认必现。

#5744 曾把 order 侧的拒绝改成「可重试」做兜底，只让状态最终能自愈，没消除 fence 被长期占用的来源，所以现象从「永久卡住」变成「必卡 10 分钟」。

二、根因（后端，接口契约无关）

fleet 释放 order 侧「用车需求最终确认 fence」的调用误用了 Result.getCheckedData() 解包 Result<Void>——该方法在 data == null 时抛 100901 远程服务返回数据为空，而释放端点固定返回 Result.success()（data 恒 null）。于是 order 侧其实已释放成功的调用，被 fleet 100% 判成失败：释放事件永远重试并阻塞同顺序键后继，fence 只能等 10 分钟租约过期；期间配车快照回调被 582092 挡回重试，订单侧 vehicle_control_status 一直是 PROCESSING。

三、变更

项 变化
fence 释放调用 改按 isSuccess() 判定（全仓 71 个 Result<Void> 端点已扫，无第二处同类误用）
释放补偿告警 重试预算耗尽时日志升级 ERROR（保留「永不隔离」设计，隔离等于 fence 永不释放）
时间字段落库 fleet/order-v3 共 4 处 UTC OffsetDateTime 直接 toLocalDateTime() 丢偏移，改为按本地时区换算

接口路径、请求/响应结构、错误码均无变化。

四、对前端的影响

  • 无需改动。
  • 行为变化 1：派车确认后订单详情「用车安排」由「车控处理中」转「已回配」不再需要等 ~10 分钟（现由分钟级 outbox 调度驱动）。此前若前端做过「10 分钟内不刷新/长轮询」之类的迁就，可以去掉。
  • 行为变化 2：以下时间字段此前比北京时间早 8 小时，现已修正为本地时间口径 —— 订单详情用车安排的配车完成时间 assignmentCompletedAt、逐日配车行的 submittedAt、车费调整时间 vehicleFeeAdjustedAt。
  • 注意：本次未做存量数据订正，修复上线前落库的历史行仍是早 8 小时的旧值，新数据起口径正确。如需订正存量另行提。

五、验证证据（2026-08-10 测试服）

端到端实测（12:26，订单 26-9313，2 车辆槽位 × 3 天，真实 API 走完「登记司机确认 → 需求级原子最终确认」）：

指标 修复前 修复后实测
fence 占用 10m01s ~ 11m13s（贴 10 分钟租约） 352 毫秒
释放事件投递 retry_count=20 永不成功 retry_count=0，一次成功
配车快照回调投递 retry_count=7 才成功 retry_count=0，一次成功
确认 → 订单侧 vehicle_control_status=DONE ~10 分钟 36 秒（12:26:24 → 12:27:00）
assignmentCompletedAt 记成 04:26（早 8 小时） 12:26:24（北京时间正确）
  • API 复验 GET /v3/admin/order/{id}/itinerary：vehicleGroup.requirement.status=DONE，assignments 6 条齐全。
  • 部署完成 12:17:28 → 12:18:00 起积压释放事件恢复成功投递（该事件类型自 08-04 起 48 条全 PENDING、0 条 SUCCESS）。
  • 单测：新增 8 例（void 成功不判失败 / 业务失败 strict 抛出 / 非 strict 降级 / 传输 null / UTC→本地换算保持时刻不变）；fleet 定向 + 架构门禁 96 绿，order-v3 全量 6291 绿。

关联 / 联系人

链接

联系人

  • 后端负责人: @wx