3.1 KiB
3.1 KiB
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 | pending | mmg | 2026-08-11 | 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)自测:定制师和房务两侧分别打开会话并发送,均应成功;发出的消息在对方抢单后应能在会话里看到。