From 1c022e7943e1205d2dd523d4fe22b72285b2bea9 Mon Sep 17 00:00:00 2001
From: API Changelog Bot <changelog@hulalv.com>
Date: Tue, 11 Aug 2026 14:43:13 +0800
Subject: [PATCH] =?UTF-8?q?changelog(frontend):=20=E6=8A=A2=E5=8D=95?=
 =?UTF-8?q?=E5=89=8D=E8=81=94=E7=B3=BB=E5=AF=B9=E6=96=B9=E5=8F=91=E4=B8=8D?=
 =?UTF-8?q?=E5=87=BA=E6=B6=88=E6=81=AF=EF=BC=88=E5=90=8E=E7=AB=AF=E5=AE=9E?=
 =?UTF-8?q?=E6=B5=8B=E5=8F=8C=E8=A7=86=E8=A7=92=E5=9D=87=E5=8F=AF=E5=8F=91?=
 =?UTF-8?q?=E9=80=81=EF=BC=89?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...单前联系对方发不出消息-前端缺陷-管理后台.md | 65 +++++++++++++++++++
 1 file changed, 65 insertions(+)
 create mode 100644 changelogs-v2/2026-08/11_frontend_抢单前联系对方发不出消息-前端缺陷-管理后台.md

diff --git a/changelogs-v2/2026-08/11_frontend_抢单前联系对方发不出消息-前端缺陷-管理后台.md b/changelogs-v2/2026-08/11_frontend_抢单前联系对方发不出消息-前端缺陷-管理后台.md
new file mode 100644
index 0000000..e1b75b3
--- /dev/null
+++ b/changelogs-v2/2026-08/11_frontend_抢单前联系对方发不出消息-前端缺陷-管理后台.md
@@ -0,0 +1,65 @@
+---
+schema: "hl-changelog/v2"
+ticket: "frontend"
+title: "房务/定制师抢单前「联系对方」发不出消息（后端实测双视角均可发送）"
+consumer: "admin"
+change_type: "前端缺陷"
+author: "wx(GIT)"
+backend_status: "not_required"
+gateway_status: "not_required"
+frontend_status: "pending"
+frontend_owner: "mmg"
+frontend_ref: ""
+target_release: ""
+verified_at: ""
+status_note: ""
+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`）自测：定制师和房务两侧分别打开会话并发送，均应成功；发出的消息在对方抢单后应能在会话里看到。