66 行
4.4 KiB
Markdown
66 行
4.4 KiB
Markdown
---
|
||
schema: "hl-changelog/v2"
|
||
ticket: "frontend"
|
||
title: "房务/定制师抢单前「联系对方」发不出消息（后端实测双视角均可发送）"
|
||
consumer: "admin"
|
||
change_type: "前端缺陷"
|
||
author: "wx(GIT)"
|
||
backend_status: "not_required"
|
||
gateway_status: "not_required"
|
||
frontend_status: "implemented"
|
||
frontend_owner: "mmg"
|
||
frontend_ref: "9b824f5c"
|
||
target_release: ""
|
||
verified_at: ""
|
||
status_note: "前端已实现(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 含生产构建全过。"
|
||
updated_at: "2026-08-11"
|
||
base: "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` 成功** |
|
||
|
||
请求体：
|
||
|
||
```json
|
||
// 开会话
|
||
POST /admin/message/chat/open-house
|
||
{"orderId": 2086425903478325250, "peerAdminId": 0}
|
||
|
||
// 发送
|
||
POST /admin/message/chat/HOUSE:2086425903478325250/messages
|
||
{"content": "房型已确认"}
|
||
→ 200 {"messageId":"...", "conversationKey":"HOUSE:...", "sentAt":"..."}
|
||
```
|
||
|
||
消息真实落库，未抢单**不影响**开会话与发送。
|
||
|
||
## 排查方向（按怀疑度排序）
|
||
|
||
1. **🔴 首要怀疑：`peerAdminId=0` 被当成「无对端」而禁用了发送按钮。** 抢单前对端是**占位 0**（真实房务还不存在），`peerName` 也为 `null`。前端若用 `peerAdminId > 0` 或 `peerName != null` 作为发送可用条件，抢单前就会整个禁用——而后端此时是允许发送的（这正是留言池的设计：定制师先留言，房务抢单后自动接收）。
|
||
2. 会话 key 的取得方式：抢单前 `open-house` 仍返回正常的 `HOUSE:{orderId}` key，不需要 peer 存在。确认前端没有因为 `peerAdminId=0` 而没去调 `open-house`、导致没有 key 可发。
|
||
3. 发送按钮的 loading / disabled 状态是否卡在某个未 resolve 的前置请求上（例如等一个抢单信息接口返回）。
|
||
4. 快捷短语点击后是否只填充了输入框、但未同步内部 state，导致发送时取到空内容被前端自己拦掉。
|
||
|
||
## 需要补充的信息
|
||
|
||
测试人员是从**哪个入口**打开这个弹窗的（房务工作台 / 订单详情 / 抢单池列表）？不同入口可能不是同一个前端组件，确认后可缩小范围。
|
||
|
||
## 验证方式
|
||
|
||
修复后用未抢单订单（如 `26-0543`）自测：定制师和房务两侧分别打开会话并发送，均应成功；发出的消息在对方抢单后应能在会话里看到。
|