From 0eecbce1abb4a19545627edfda4722651f4eab0f Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Sat, 19 Sep 2026 14:30:07 +0800 Subject: [PATCH] =?UTF-8?q?docs(changelog):=20#7442=20=E8=AE=A2=E6=AD=A3?= =?UTF-8?q?=E4=B8=A4=E4=BB=BD=E4=BA=A4=E6=8E=A5=E4=BB=B6=E7=9A=84=E9=83=A8?= =?UTF-8?q?=E7=BD=B2=E9=A1=BA=E5=BA=8F=E7=BB=93=E8=AE=BA=E2=80=94=E2=80=94?= =?UTF-8?q?=E6=8C=89=E5=8D=95=E7=AE=97=E7=9A=84"=E9=A1=BA=E5=BA=8F?= =?UTF-8?q?=E6=97=A0=E6=89=80=E8=B0=93"=E5=9C=A8=E5=B9=B6=E9=9B=86?= =?UTF-8?q?=E9=87=8C=E6=98=AF=E9=94=99=E7=9A=84?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 两份文档各有一句部署顺序结论： - reconfigure 补登：「万一要分批，order-v3 先滚风险更低」 - 就绪回写补登：「本单不强制要求特定先后顺序」 两句按各自那次改动算都是对的，分析段也都标了范围（reconfigure 那份甚至 明写「本单与 #7957 的『fleet 必须先滚』不同」）。错的是结论句把限定丢了， 读起来像是对这次部署的建议。 而 PR-C2（#7957）后来在同一个 GroupBatchDispatchBaselineDTO 上加了 reconfigureWindow，它强制 fleet 先于 order-v3：order-v3 先滚时旧 fleet 收到 dispatchable=true 直接放行重配，不读 reconfigureWindow、不校验令牌 与范围，「受控重开」当场退化成「不受控重开」——而两端日志都正常、 没有任何报错。今天要部署的人面对的是这些改动的并集，不是某一单。 ⇒ 两份都补了订正框，并把实操答案写死：同批滚；必须分批时 fleet 先、 order-v3 后。同时立了一条规矩：写部署顺序结论一律带上「截至某日期/commit， 这个 DTO / 这批部署单位上还有哪些已合入的改动」这个限定——按单写的部署 结论会在下一次改动落到同一个对象上时变成陷阱，而它不报错，也没有人会 回来改它。 原分析段逐字保留，只给结论句补范围。 Refs #7442 Co-Authored-By: Claude Opus 5 (1M context) --- ...分组写口reconfigure补登-新增接口-管理后台.md | 24 +++++++++++++++---- ...绪回写带身份两级判定补登-修改接口-管理后台.md | 18 ++++++++++---- 2 files changed, 34 insertions(+), 8 deletions(-) diff --git a/changelogs-v2/2026-09/19_7442_团期配车分组写口reconfigure补登-新增接口-管理后台.md b/changelogs-v2/2026-09/19_7442_团期配车分组写口reconfigure补登-新增接口-管理后台.md index 2fc26916..85b1d4f0 100644 --- a/changelogs-v2/2026-09/19_7442_团期配车分组写口reconfigure补登-新增接口-管理后台.md +++ b/changelogs-v2/2026-09/19_7442_团期配车分组写口reconfigure补登-新增接口-管理后台.md @@ -300,8 +300,23 @@ POST /admin/fleet/group-dispatch/batches/1934567890123456800/reconfigure 乘车分组清单」），**这是本单与 PR-C2 最大的不同**：PR-C2 的 `dispatchable` 放宽会被旧 fleet 静默忽略、 放行了本不该放行的请求；本单缺 `groups[]` 则是**整个新端点在这段时间内全部请求都报 602009**——响应是 **明确的错误码，不是静默放行**，运营/车务会立刻发现"这功能用不了"而不是"这功能用了但结果不对"。 -- **结论**：两个方向都不会产生数据错乱，区别只是"功能完全不可用一段时间"（fleet 先滚）还是"零影响" - （order-v3 先滚）。**仍然建议同批滚**（消除过渡期报错），但万一要分批，**order-v3 先滚风险更低**。 +- **结论（⚠️ 只对本单这一次改动成立，不要拿它指导今天的部署）**：**单看本单**，两个方向都不会产生 + 数据错乱，区别只是"功能完全不可用一段时间"（fleet 先滚）还是"零影响"（order-v3 先滚）。 + +> 🔴 **2026-09-19 订正：上面那句"order-v3 先滚风险更低"是按本单单独算的，拿它指导实际部署会出事。** +> PR-C2（#7957，2026-09-18 合入）**后来在同一个 `GroupBatchDispatchBaselineDTO` 上又加了 +> `reconfigureWindow`**，而今天要部署的人面对的是**两次改动的并集**，不是本单。 +> 对并集而言正确答案是 **fleet 必须先于 order-v3**：order-v3 先滚 ⇒ 旧 fleet 收到 `dispatchable=true` +> 直接放行重配，它不读 `reconfigureWindow`、不校验令牌与范围 ⇒ **「受控重开」当场退化成「不受控重开」， +> 而两端日志都正常、没有任何报错**（详见 `19_7442_团期配车受控重开窗口计划刷新状态收口…md`「部署清单」 +> 与 PR [#7957](https://git.1814.love:8443/wx/HL/pulls/7957) 正文「⚠️ 部署：fleet 必须先于 order-v3」）。 +> +> ⚠️ 上面那段按单分析**本身没错、也标了范围**（见本节标题与开头那句「本单与 #7957 的『fleet 必须先滚』 +> 不同」）——错的是**结论句把限定丢了**，读起来像是对这次部署的建议。 +> **按单写的部署结论会在下一次改动落到同一个 DTO 上时变成陷阱**，而它不会报错、也没有人会回来改它。 +> ⇒ 今后写部署顺序结论，一律带上「**截至 <日期/commit>，本 DTO 上还有哪些已合入的改动**」这个限定。 + +**⇒ 今天的实操答案：同批滚；必须分批时 `fleet` 先、`order-v3` 后。** ### 消费方清单不能按 `pom.xml` 直接依赖关系查 @@ -309,8 +324,9 @@ POST /admin/fleet/group-dispatch/batches/1934567890123456800/reconfigure `grep -rl 'hl-common-core' */pom.xml` 只命中 `hl-gateway`/`hl-finance`，order-v3 与 fleet 都经 `hl-common-web` 传递引入，不在直接依赖清单里，但正是本单真正改了代码的两个服务。 -⇒ **实际部署单位共 7 个**：gateway / user / resource / product-v2 / order-v3 / mp / fleet； -本单不强制要求特定先后顺序，但**同批滚**仍是最稳妥的做法。 +⇒ **实际部署单位共 7 个**：gateway / user / resource / product-v2 / order-v3 / mp / fleet。 +**同批滚**；必须分批时 **`fleet` 先、`order-v3` 后**（理由见上方 2026-09-19 订正框—— +本单自身不强制顺序，但同一个 DTO 上的 PR-C2 强制了，今天部署的是两者的并集）。 --- diff --git a/changelogs-v2/2026-09/19_7442_团期配车就绪回写带身份两级判定补登-修改接口-管理后台.md b/changelogs-v2/2026-09/19_7442_团期配车就绪回写带身份两级判定补登-修改接口-管理后台.md index 144d8f66..dd014e5e 100644 --- a/changelogs-v2/2026-09/19_7442_团期配车就绪回写带身份两级判定补登-修改接口-管理后台.md +++ b/changelogs-v2/2026-09/19_7442_团期配车就绪回写带身份两级判定补登-修改接口-管理后台.md @@ -396,8 +396,17 @@ POST /v3/internal/group-batch/1934567890123456800/vehicle-ready-reset 不会报错也不会解析失败，等价于"这个请求体被忽略了"，order-v3 仍按改动前的无身份逻辑处理。**净效果**： 两级判定这项保护在这段过渡期内**还没有生效**（旧漏洞——乱序/旧版回调污染就绪状态——仍然存在）， 但不会比改动前更糟，也不会报错或崩溃。 -- **结论**：两个方向都不会比"改动前"更差，区别只是"保护何时开始生效"。**仍建议同批滚**，让两级判定 - 尽快对新回调生效，避免过渡期内继续吃"旧漏洞"的亏。 +- **结论（⚠️ 只对本单这一次改动成立，不要拿它指导今天的部署）**：**单看本单**，两个方向都不会比 + "改动前"更差，区别只是"保护何时开始生效"。 + +> 🔴 **2026-09-19 订正：不要据此认为"顺序无所谓"。**本单自身确实不挑顺序，但**同期还有别的改动** +> 落在同一批部署单位上——PR-C2（#7957）在 `GroupBatchDispatchBaselineDTO` 上加了 `reconfigureWindow`， +> 它**强制 `fleet` 先于 `order-v3`**（order-v3 先滚 ⇒ 旧 fleet 不校验窗口令牌，「受控重开」静默退化成 +> 「不受控重开」，两端日志都正常）。今天部署的是这些改动的**并集**。 +> ⚠️ **按单写的"顺序无所谓"，在并集里就是错的**，而且它不会报错、没有人会回来改它。 +> ⇒ 写部署顺序结论一律带限定：「**截至 <日期/commit>，这批部署单位上还有哪些已合入的改动**」。 + +**⇒ 今天的实操答案：同批滚；必须分批时 `fleet` 先、`order-v3` 后。** ### 消费方清单不能按 `pom.xml` 直接依赖关系查 @@ -405,8 +414,9 @@ POST /v3/internal/group-batch/1934567890123456800/vehicle-ready-reset `grep -rl 'hl-common-core' */pom.xml` 只命中 `hl-gateway`/`hl-finance`，order-v3 与 fleet 都经 `hl-common-web` 传递引入，不在直接依赖清单里，但正是本单真正改了代码的两个服务。 -⇒ **实际部署单位共 7 个**：gateway / user / resource / product-v2 / order-v3 / mp / fleet；本单不强制 -要求特定先后顺序，但**同批滚**仍是最稳妥的做法。 +⇒ **实际部署单位共 7 个**：gateway / user / resource / product-v2 / order-v3 / mp / fleet。 +**同批滚**；必须分批时 **`fleet` 先、`order-v3` 后**（本单自身不挑顺序，但同期 PR-C2 挑， +今天部署的是并集——见上方 2026-09-19 订正框）。 ### 🔧 2026-09-19 补充取证：PR 正文与本节结论的矛盾判定依据