hl-api-changelog

2,903 提交 29 分支 0 Git 标签

3 次代码提交

包含重命名

作者	SHA1	备注	提交日期
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

作者

SHA1

备注

提交日期

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