From 4b062a298a01e738a98e2f791b87cece13bcc662 Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Tue, 30 Jun 2026 11:36:23 +0800 Subject: [PATCH] =?UTF-8?q?docs(changelog-v2):=20=E4=BF=AE=E6=AD=A356=5F?= =?UTF-8?q?=E7=AB=99=E5=86=85=E4=BF=A1=E7=BA=A2=E7=82=B9=E2=80=94=E2=80=94?= =?UTF-8?q?=E6=A0=B9=E5=9B=A0=E6=94=B9=E4=B8=BA=E5=89=8D=E7=AB=AF=E3=80=8C?= =?UTF-8?q?=E5=85=A8=E9=83=A8=E3=80=8Dtab=E6=94=B6=E5=88=B0=E5=8D=B4?= =?UTF-8?q?=E4=B8=8D=E6=B8=B2=E6=9F=93(=E9=9D=9E=E6=B2=A1=E5=88=B7?= =?UTF-8?q?=E6=96=B0),=E9=99=84Network=E5=AE=9E=E8=AF=81records[0]?= =?UTF-8?q?=E5=90=AB=E8=AF=A5=E6=B6=88=E6=81=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...全部tab收到却不渲染_前端去重过滤bug_前端处理-管理后台.md | 59 +++++++++++++++++++ ...进消息列表_前端收CHAT-SSE要刷列表_前端处理-管理后台.md | 26 -------- 2 files changed, 59 insertions(+), 26 deletions(-) create mode 100644 changelogs-v2/2026-06/56_房务抢单后定制师预留言_站内信全部tab收到却不渲染_前端去重过滤bug_前端处理-管理后台.md delete mode 100644 changelogs-v2/2026-06/56_房务抢单后定制师预留言未刷进消息列表_前端收CHAT-SSE要刷列表_前端处理-管理后台.md diff --git a/changelogs-v2/2026-06/56_房务抢单后定制师预留言_站内信全部tab收到却不渲染_前端去重过滤bug_前端处理-管理后台.md b/changelogs-v2/2026-06/56_房务抢单后定制师预留言_站内信全部tab收到却不渲染_前端去重过滤bug_前端处理-管理后台.md new file mode 100644 index 0000000..13f0482 --- /dev/null +++ b/changelogs-v2/2026-06/56_房务抢单后定制师预留言_站内信全部tab收到却不渲染_前端去重过滤bug_前端处理-管理后台.md @@ -0,0 +1,59 @@ +# 房务抢单后，定制师「抢单前发的联系房务消息」红点有、站内信「全部」tab 看不到（前端已收到却没渲染） + +> 模块：管理后台 · 站内信/我的消息「全部」tab + 房务抢单 +> 类型：**前端处理**（后端已逐项核实正确，无需改后端） +> 日期：2026-06-30 +> 反馈来源：wx 手动测试（含浏览器 Network 抓包） +> 说明：**本文修正同目录早前版本的根因**——早前写「前端收 CHAT SSE 没刷列表、红点更新了列表没更新」。经浏览器 Network 抓包实证：**列表接口已把该消息正确返回给浏览器（就在 `records[0]`），前端拿到却没渲染**，根因不是「没刷新」而是「全部 tab 渲染时把这条最新订单消息过滤/去重掉了」。请以本文为准。 + +## 现象 +定制师在**房务还没抢单时**发「联系房务」消息；房务（admin=1001）抢单后： +- 顶部铃铛红点 **+1（未读=1）**✅； +- 但「我的消息 → 全部」列表里**看不到那条新消息**，列表「共 10 条」，缺了最新这条； +- **手动整页刷新后仍然看不到**（排除「列表没刷新」的时序问题）。 + +## 关键实证（浏览器 Network 抓包） +「全部」tab 拉的 `GET /admin/message/list?pageSize=20&pageNo=1` 响应里，**`records[0]` 就是这条缺失的消息**，字段齐全可渲染： + +```json +{ + "messageId": "2071792080350236674", + "categoryCode": null, + "title": "HL20260630103610215 · 吕思远", // 已 enrich 成「团号 · 联系人」 + "content": "77721", + "link": null, + "bizId": "2071784830965620737", + "bizType": "HOUSE", + "isRead": 0, + "createTime": 1782788699000, // 2026-06-30 11:04，本页最新一条 + "messageType": "ORDER", + "messageTypeLabel": "订单消息", + "kind": "CHAT", + "senderName": "王骁", + "conversationKey": "HOUSE:2071784830965620737" +} +``` + +即：**后端把这条订单消息作为本页第一条（最新）正确返回了**，但页面「共 10 条」、左侧列表里没有它（列表渲染的最旧 CHAT 行是 06-28 的，更早的 06-19 都在，唯独这条 06-30 最新的被丢）。 + +## 后端现状（已逐项核实正确，勿改后端） +1. **消息归属迁移**：抢单/转单后 order-v3 经 Feign 调 user-service `bindHouseClaimer`，把抢单前 pending（receiver=0）消息改判给真实抢单房务（`admin_message.admin_id` → claimer）。实测该行已落到 admin=1001 名下（kind=CHAT / messageType=ORDER / is_read=0）。 +2. **会话成员迁移**：同一事务里同步「补/对齐房务成员行」（`admin_conversation_member`），claimer 成为该会话有效成员——所以这条会话在**收件箱 `list`** 和**会话列表 `conversations`** 两个端点对 claimer 都可见，不是「孤儿消息」。 +3. **分页 total 正确**：`list` 走 MyBatis-Plus 分页，`total` 来自同 wrapper 的 COUNT；列表装配只对 CHAT 行批量 enrich 标题（团号·联系人），**不增删行**。故响应 `total` 与 `records` 一致（本页含这条共 N 条），后端没有少返。 +4. **SSE 已发**：迁移真有新消息送达时发 `type=CHAT` 信令（Redis `admin-notify`），携 `unreadCount / conversationKey / senderName / preview`，前端红点已据此 +1（与现象一致）。 + +→ **后端数据完整一致**：消息行 + 会话成员行都迁移到位、total 正确、SSE 已发、`list` 已把该消息作为 `records[0]` 返回给浏览器。 + +## 根因（前端：收到了却没渲染） +前端「全部」tab 在渲染 `list` 响应时，把这条**刚迁移来的最新 CHAT（订单消息）行过滤/去重掉了**。可能方向（请前端自查）： +- 「全部」列表对 `kind=CHAT` 行**按 `conversationKey` 去重**（一会话一行），而此会话 `HOUSE:2071784830965620737` 与已渲染的某历史行（同一会话/同一对端「王骁」）判为重复，保留了旧行、丢了这条最新行； +- 或把 `list` 里的 CHAT 行与 `conversations`（会话列表）做合并/抵扣，导致这条新会话消息在「全部」里被会话列表项「吸收」而不在消息流里单独显示； +- 或对 `categoryCode=null` / `link=null` 的 CHAT 行有渲染守卫，把它跳过（注意：正常订单消息本就 `categoryCode=null`、`link=null`，不应据此跳过）。 + +## 【前端处理】 +请检查「我的消息 → 全部」tab 对 `GET /admin/message/list` 响应的渲染逻辑，**确保 `kind=CHAT`（订单消息）行——尤其房务抢单后刚迁移来的最新会话消息（如 `records[0]`）——不被去重/过滤掉**： +- 列表应忠实渲染 `records` 全量（含 `messageType=ORDER` 的 CHAT 行），若要按会话去重也应**保留每个会话的最新一条**（而非保留旧行丢新行）； +- 不要因 `categoryCode=null` / `link=null` 跳过 CHAT 行（订单消息正常就是这俩为 null）； +- 排查重点：复现「房务抢单 → 全部 tab 整页刷新」，对照 Network 响应里 `records[0]` 是否被渲染。后端已确认该条在响应中，前端只需把它渲染出来即可。 + +> 补充：定制师抢单前发的消息属「订单消息」（kind=CHAT / messageType=ORDER / bizType=HOUSE），抢单后归属迁移给抢单房务即应出现在其「我的消息 → 全部 / 订单消息」中——这是后端既有且已验证的行为，前端把这条已在响应中的记录正确渲染出来即可。 diff --git a/changelogs-v2/2026-06/56_房务抢单后定制师预留言未刷进消息列表_前端收CHAT-SSE要刷列表_前端处理-管理后台.md b/changelogs-v2/2026-06/56_房务抢单后定制师预留言未刷进消息列表_前端收CHAT-SSE要刷列表_前端处理-管理后台.md deleted file mode 100644 index d368c0d..0000000 --- a/changelogs-v2/2026-06/56_房务抢单后定制师预留言未刷进消息列表_前端收CHAT-SSE要刷列表_前端处理-管理后台.md +++ /dev/null @@ -1,26 +0,0 @@ -# 房务抢单后，定制师「抢单前发的联系房务消息」红点有、消息列表看不到（前端收 CHAT SSE 要刷列表） - -> 模块：管理后台 · 站内信/我的消息 + 房务抢单 -> 类型：**前端处理**（后端已正确，无需改后端） -> 日期：2026-06-30 -> 反馈来源：wx 手动测试 - -## 现象 -定制师在**房务还没抢单时**发「联系房务」消息；房务抢单后，**顶部铃铛红点 +1（有未读）**，但「我的消息」列表里**看不到那条新消息**（列表停在抢单前的旧数据），需手动刷新才出现。 - -## 后端现状（已正确，勿改后端） -1. 抢单/转单后，order-v3 经 Feign 调 user-service `bindHouseClaimer`，把抢单前的 pending（receiver=0）消息**归属迁移给真实抢单房务**（admin_message.admin_id 改判为 claimer）。实测：该消息已正确落到房务名下（kind=CHAT / messageType=ORDER）。 -2. 迁移「真有新消息送达」时，后端发 **SSE 信令**（Redis 频道 `admin-notify`），payload 字段齐全： - ```json - { "type": "CHAT", "adminId": <抢单房务id>, "unreadCount": <合并未读数>, - "conversationKey": "HOUSE:", "senderName": "<定制师名>", "preview": "<消息预览>", "priority": "..." } - ``` -3. 列表接口 `GET /admin/message/list`（含 `messageType=ORDER` 订单消息 tab）**已正确返回该消息**（实测置顶），未读数接口 `GET /admin/message/unread-count` 也正确 +1。**后端数据一致**。 - -## 根因（前端） -前端收到 `type=CHAT` 的 SSE 信令后，**只用 `unreadCount` 刷新了顶部红点角标，没有刷新/更新「我的消息」列表**（把 CHAT 信令仅当聊天面板信令处理，没联动站内信「订单消息」列表）。→ 红点更新了、列表没更新，造成「有红点、列表看不到」。 - -## 【前端处理】 -收到 `type=CHAT` 的 SSE 信令时，除刷新顶部红点角标（`unreadCount`）外，**同时刷新/重拉「我的消息」列表**（尤其「订单消息」tab）——或按 payload 的 `conversationKey`/`senderName`/`preview` 在列表插入/置顶该会话最新消息。否则房务抢单后新到的订单消息在列表里看不到（红点有、列表无），用户需手动刷新。 - -> 补充：定制师抢单前发的消息属「订单消息」（kind=CHAT / messageType=ORDER），抢单后归属迁移给抢单房务即应出现在其「我的消息 → 订单消息」中——这是后端既有行为，前端只需在 CHAT 信令到达时刷新列表即可。