文件

T

changelog-filename-gate / validate (push) Failing after 2s

详情

chore(changelog): 全量清理 implemented 存量——81 条复核翻 verified + 1 条改判 not_required + #5827 补登 frontend_ref

处置明细(mmg 2026-09-18):
- 68 条机械核验通过批量翻 verified:frontend_ref 均可达且为 v2.1 祖先、
  交付文件 HEAD 均在、关联 spec 批量 58 文件 891 例全绿。
- 11 条带演进史的例外逐条核后翻 verified:3 条交付自删文件(06_5610/
  07_5655/11_5810,删除即交付内容且终态保持);8 条被后续 changelog 预期
  演进(10_5784→#5810、07_5664/08_5592→#5827、07_5665→去槽位化 U1、
  01_5380/05_5356/06_5567/06_5581→settlement 族A扁平化与 mock 清理),
  status_note 均如实记录演进链。
- 05_5552 改判 not_required:frontend_ref 自述前端无需改动,grep 实证
  vehicleFeeAmount.js 直接读后端 calendarPrice/calendarPriceMissing。
- 11_5827 frontend_ref 原空,经核交付即 753503c8(向导 4 步改 3 步提交
  即派定),补登全哈希 753503c87cc635e5646b4368a8ed506746c79cf1。
另:保险域 2 条相邻条目(05_5530/06_5593)同标准复核翻 verified。
2026-07 历史月 45 条按规则不回扫,保持原状。

2026-09-18 15:56:52 +08:00

4.5 KiB

原始文件 Blame 文件历史

schema, ticket, title, consumer, change_type, author, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base

schema	ticket	title	consumer	change_type	author	backend_status	gateway_status	frontend_status	frontend_owner	frontend_ref	target_release	verified_at	status_note	updated_at	base
hl-changelog/v2	frontend	房务/定制师抢单前「联系对方」发不出消息（后端实测双视角均可发送）	admin	前端缺陷	wx(GIT)	not_required	not_required	verified	mmg	9b824f5c		2026-09-18	前端已实现(9b824f5c)。changelog 怀疑的「peerAdminId=0 禁用发送」不成立：canSend/sendContent 门禁均不含 peerAdminId，open-house 对 '0' 传 '0' 后端返 200，emit 链全程无门禁。Workflow 对抗审查代码级证实真实根因——非抢单专属，是 request.js 通用缺陷：access token 过期(页面闲置首开聊天常见)时 open-house POST 首试在 shouldDedupe 写时间戳，后端业务体 401 → tryRefreshAndRetry 只清 signal/__requestKey 不清 writeRequestTimestamps，refresh 零延迟重放距首试 <300ms 被误判重复写、预 abort 抛 CanceledError，经 openFlow catch 的 isCanceledRequest 静默吞 → conversationKey 永不赋值，但标题因 peerName 空兜底仍显示「待接单房务」看似正常 → sendContent 因 key 空静默 return(=点发送无反应)。curl 持新鲜 token 不经 401 重放必 200，与观测吻合。修复：① request.js 两条重放路径(401 refresh 重放 + 5xx/限流重试)统一 config.dedupe=false(重放是合法重发非重复提交);② ChatDrawer open 失败(非主动取消)时 message.error 提示并关抽屉,不留死抽屉。测试:request.spec +2(修复前精确复现 CanceledError)37/37,ChatDrawer.spec +2 6/6,全量 190 文件 1780 用例全绿,checkpoint 含生产构建全过。[mmg 2026-09-18 批量复核翻 verified] ref 9b824f5c 可达且为 v2.1 祖先;交付文件 HEAD 均在;关联 spec 批量 891 例全绿。	2026-09-18	dev-v3

抢单前「联系定制师 / 联系房务」发不出消息（2026-08-11 测试人员反馈）

页面：房务订单会话弹窗（标题显示「待接单房务」）现象：房务尚未抢单时打开会话，输入内容点发送按钮无反应 / 发不出去后端：本条无后端改动，抢单前的留言池链路后端完全正常，实测数据见下

后端实测（2026-08-11 网关 9443）

用真正未抢单的订单复现：26-0543（orderId 2086425903478325250，house_status=PENDING_CLAIM、claimer_id 为 NULL），定制师 / 房务两个视角都实测：

视角（角色）	`POST /admin/message/chat/open-house`	`POST /admin/message/chat/{key}/messages`
定制师（CUSTOMIZER）	`code=200`，key=`HOUSE:2086425903478325250`，`peerAdminId=0`（占位）	`code=200` 成功
房务（ROOM_MANAGER）	`code=200`，同一 key，`peerAdminId=0`（占位）	`code=200` 成功

请求体：

// 开会话
POST /admin/message/chat/open-house
{"orderId": 2086425903478325250, "peerAdminId": 0}

// 发送
POST /admin/message/chat/HOUSE:2086425903478325250/messages
{"content": "房型已确认"}
→ 200 {"messageId":"...", "conversationKey":"HOUSE:...", "sentAt":"..."}

消息真实落库，未抢单不影响开会话与发送。

排查方向（按怀疑度排序）

🔴 首要怀疑：peerAdminId=0 被当成「无对端」而禁用了发送按钮。 抢单前对端是占位 0（真实房务还不存在），peerName 也为 null。前端若用 peerAdminId > 0 或 peerName != null 作为发送可用条件，抢单前就会整个禁用——而后端此时是允许发送的（这正是留言池的设计：定制师先留言，房务抢单后自动接收）。
会话 key 的取得方式：抢单前 open-house 仍返回正常的 HOUSE:{orderId} key，不需要 peer 存在。确认前端没有因为 peerAdminId=0 而没去调 open-house、导致没有 key 可发。
发送按钮的 loading / disabled 状态是否卡在某个未 resolve 的前置请求上（例如等一个抢单信息接口返回）。
快捷短语点击后是否只填充了输入框、但未同步内部 state，导致发送时取到空内容被前端自己拦掉。

需要补充的信息

测试人员是从哪个入口打开这个弹窗的（房务工作台 / 订单详情 / 抢单池列表）？不同入口可能不是同一个前端组件，确认后可缩小范围。

验证方式

修复后用未抢单订单（如 26-0543）自测：定制师和房务两侧分别打开会话并发送，均应成功；发出的消息在对方抢单后应能在会话里看到。

4.5 KiB 原始文件 Blame 文件历史 Unescape Escape