wx/hl-api-changelog
1
0
派生 0
代码 工单 合并请求 工作流 软件包 项目 发布 百科 活动
3,112 提交 29 分支 0 Git 标签
2e3b0e892c9c92f1e1c8a7ed111481725dd0fd16
提交图
4 次代码提交
作者 SHA1 备注 提交日期
Mimingguang ac12dabe20 docs(changelog): #7443 C 车务侧+13_7439/18_7443/20_7990 前端已交付 verified(hl-admin v2.1 662310ea/6c091ef24)
changelog-filename-gate / validate (push) Failing after 2s
详情 
18_7443 挂起期回头补落地(派车弹窗 kind 切换+batch/pickup-dropoff-config 显式 kind);
20_7990 requirementIdentities 已消费;13_7439 硬契约点 A+B 已补(809008/显式 kind/reject 走 query);
20_7443 AC-24 维持 not_required 仅补 C 段实证
 2026-09-21 17:52:22 +08:00
Mimingguang 5db14d3832 chore(changelog): #7439 用车需求分家前端 not_required（等 TRANSFER 开放）
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-13 15:10:28 +08:00
API Changelog Bot 1c5279f327 docs(changelog): #7439 对外分册补齐 809001/809007 处置口径与「建议显式传 kind」
changelog-filename-gate / validate (push) Failing after 2s
详情 
两处是交接件自身的缺口，不是实现问题：

1. 809001（同单同 kind 重复/并发提交）此前只作为 JSON 示例出现，没有前端处置口径，
   而本文件错误码表的前提就是「每个码配一条处置口径——码本身不够，处置动作错了
   照样是线上问题」。补的处置口径关键是「不要自动重试」：只要那条活跃需求还在，
   重试永远是这个码。
2. 809007 此前只在内部分册。它确实是 fleet 消费侧的码、前端拿不到，但错误码段位
   在交接件里应当完整，且它与 809002 的分工需要说清（809002=提交时派生不出来，
   前端可引导补大交通；809007=提交时没派生、事后被消费，属存量回填，前端无动作）。
   补上之后，「交接件含 6 个错误码」在「两册之和」与「mmg 实际拿到的那一份」
   两种读法下都成立，不必再去裁哪种读法对。
3. 「不传 kind 按 TRAVEL 处理，现网代码可不改但建议显式传」此前只写在内部分册，
   而内部分册的收件人是后端与 fleet 侧、不是 mmg。已补进对外分册的影响评估与
   端点1 入参表，并写明为什么值得显式传：一旦该订单出现两类活跃需求，「不传」
   的语义就从「就是行程用车」变成「碰巧落到行程用车上」，两者在代码里长得一样。

校验：六个码（809000/809001/809002/809007/809008/809009）在对外册均为行首表格行
各 1 行；退役号 809003-809006 阴性对照各 0 命中；endpoint-count 仍为 7 / 4。
 2026-09-13 15:01:15 +08:00
API Changelog Bot 1e8404a047 docs(changelog): #7439 团期车务地基——用车需求分家（对外 7 端点 + 内部 4 端点）
changelog-filename-gate / validate (push) Failing after 1s
详情 
两份分册按 BACKEND_CHANGELOG_DELIVERY_GUIDE.md 2.5 节拆分（/v3/internal 必须单独成篇）。
2026-09-13 测试环境逐端点实测：对外 7 个经网关，内部 4 个直连服务带 X-Internal-Token
（网关按设计一律 403 拦 internal，不是路由失败）。部署 HEAD a82367e15，
order-v3 / fleet / gateway 同批。

实测顺带订正两处文档与实现不符的契约，已改在 §二/§三 正文而非附注：
1. 打回·定制师 / 打回·车控 的 kind 是 @RequestParam Query 参数，不在 RejectReqVO 里。
   原文档标成 Body —— 按原文档把 kind 塞进 JSON 会被 Jackson 静默忽略、
   不报错也不返 400、服务端按默认 TRAVEL 处理，接送机的打回会落到行程需求上。
2. 提交/修改用车需求的非法 kind 实测返 400（VehicleRequirementReqVO 的 @Pattern
   先于业务代码拦截），809000 对该端点的 body 参数不可达；809000 仍可经内部接口的
   query 入口触发。同一处校验、两个入口两种表现，两条分支都要处理。
 2026-09-13 14:47:04 +08:00