chore(changelog): #8061/#7980 三批同名锁回写 mmg 前端实证,翻 not_required
changelog-filename-gate / validate (push) Failing after 1s
changelog-filename-gate / validate (push) Failing after 1s
这个提交包含在:
@@ -7,12 +7,12 @@ author: "wx(GIT)"
|
||||
change_type: "修改接口"
|
||||
backend_status: "deployed"
|
||||
gateway_status: "not_required"
|
||||
frontend_status: "pending"
|
||||
frontend_status: "not_required"
|
||||
frontend_owner: "mmg"
|
||||
frontend_ref: ""
|
||||
target_release: ""
|
||||
verified_at: ""
|
||||
status_note: "PR #8069 已 squash 合并 dev-v3(合并提交 b9738a20f)。2026-09-20 23:24 已部署测试服 hl-order-service-v3:滚动更新两实例,部署前 COMMIT=c35251b07、部署后 COMMIT=ba8aab3ab,8186 与 8086 各 12 秒内起监听。`git merge-base --is-ancestor b9738a20f ba8aab3ab` 返回 ANCESTOR_YES。🔴 并且部署前 `b9738a20f` 确实不在 `c35251b07` 内(同一判据返回 NO),即本次部署是真正的「从不生效到生效」,不是重跑一遍确认。gateway_status=not_required:端点路径/方法零变化,本次与网关路由无关,不是漏验证。🔴 本次未在测试服做功能调用取证,这是有意为之而不是遗漏:这 7 个端点全是写口(`submit` / `confirmDay` / `updatePlacement` / `clearAssignments` / `clearAssignmentsByDay` / `transfer` / `release`),调用它们会真实改动配房行与库存记账,而测试服的房务数据被多个会话共用,`clear` 与 `release` 造成的后果撤不回来——副作用会落在一个不知情的人头上。互斥本身由落库级并发 IT `HouseRequirementWriteLockConcurrencyIT` 覆盖:绿轮 `house_hotel_assignment(active)=[]`、`house_dual_deduction_log(持有中)=[]`,submit 挂起 1109ms、锁键只有一把;变异轮(拆掉 7 处 `name`)留下 1 行孤儿 + 库存未释放,submit 只挂 213ms、两个键且其中一个带方法名。这比任何测试服抓包都更直接。⚠️ `100503` 在测试服上一次都没有触发过——不是「测过、不会触发」,是没测;临界区短不等于永不超时,更长事务/更大载荷/生产数据量下仍可能出现。"
|
||||
status_note: "PR #8069 已 squash 合并 dev-v3(合并提交 b9738a20f)。2026-09-20 23:24 已部署测试服 hl-order-service-v3:滚动更新两实例,部署前 COMMIT=c35251b07、部署后 COMMIT=ba8aab3ab,8186 与 8086 各 12 秒内起监听。`git merge-base --is-ancestor b9738a20f ba8aab3ab` 返回 ANCESTOR_YES。🔴 并且部署前 `b9738a20f` 确实不在 `c35251b07` 内(同一判据返回 NO),即本次部署是真正的「从不生效到生效」,不是重跑一遍确认。gateway_status=not_required:端点路径/方法零变化,本次与网关路由无关,不是漏验证。🔴 本次未在测试服做功能调用取证,这是有意为之而不是遗漏:这 7 个端点全是写口(`submit` / `confirmDay` / `updatePlacement` / `clearAssignments` / `clearAssignmentsByDay` / `transfer` / `release`),调用它们会真实改动配房行与库存记账,而测试服的房务数据被多个会话共用,`clear` 与 `release` 造成的后果撤不回来——副作用会落在一个不知情的人头上。互斥本身由落库级并发 IT `HouseRequirementWriteLockConcurrencyIT` 覆盖:绿轮 `house_hotel_assignment(active)=[]`、`house_dual_deduction_log(持有中)=[]`,submit 挂起 1109ms、锁键只有一把;变异轮(拆掉 7 处 `name`)留下 1 行孤儿 + 库存未释放,submit 只挂 213ms、两个键且其中一个带方法名。这比任何测试服抓包都更直接。⚠️ `100503` 在测试服上一次都没有触发过——不是「测过、不会触发」,是没测;临界区短不等于永不超时,更长事务/更大载荷/生产数据量下仍可能出现。mmg 前端实证 2026-09-20:七写口封装于 api/housekeeper/assignment.js(submit/update/placement/delete/clearAll/clearDay/confirmDay)与 api/housekeeper/grab-pool.js(transfer/release);调用方 OrderDetailModal.vue(catch{}+finally:1116 复位)与 housekeeper/orders/index.vue(:683-684 注释「业务错误已由 request.js 拦截器统一弹 message」、:829-830「808021 等由拦截器弹出;保持弹窗供重试」)均为拦截器透 message 模式。100503(HTTP 200+业务码)命中 request.js 拦截器统一 toast「资源被占用,请稍后重试」原样展示——可重试/不静默/不当系统异常三条全满足,不建前端业务码字典(同发票 AC-4 先例),故前端零改动,翻 not_required。"
|
||||
updated_at: "2026-09-20"
|
||||
base: "dev-v3"
|
||||
---
|
||||
|
||||
在新工单中引用
屏蔽一个用户