docs(changelog-v2): 房务抢单后预留言红点有列表无——前端收CHAT-SSE要刷消息列表(后端已正确)
这个提交包含在:
父节点
4861573da1
当前提交
d9a38d433d
@ -0,0 +1,26 @@
|
||||
# 房务抢单后,定制师「抢单前发的联系房务消息」红点有、消息列表看不到(前端收 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:<orderId>", "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 信令到达时刷新列表即可。
|
||||
正在加载...
x
在新工单中引用
屏蔽一个用户