240 lines
13 KiB
Markdown
240 lines
13 KiB
Markdown
# IM 后端问题报告：好友申请通过后 `friend_added` 系统提示被投递到旧命名话题 `usr<uid>`，同一会话存在两套 Topic
|
||
|
||
> 报告日期：2026-09-13
|
||
> 客户端：iOS（MeetingIM Swift SDK）
|
||
> 涉及账号：`usrv97xq86jw3c`（echarles5，**通过人本人**，本报告取证端）、`usrHnkwn8VSfKc`（charles1，**申请人**）
|
||
> 涉及话题：`usrHnkwn8VSfKc`（旧标准命名）与 `p2pv97xq86jw3ceeTCfxVJ8pw`（后端内部命名）
|
||
> 优先级建议：**高**（会话列表消息与未读不更新，用户可见）
|
||
|
||
---
|
||
|
||
## 1. 问题概述
|
||
|
||
好友申请通过后，服务端把一条**会话内系统提示** `system_notice / friend_added`（"你们已成为好友，现在可以开始聊天了。"）下发到了
|
||
|
||
- ❌ `usrHnkwn8VSfKc`（MeetingIM 的 `usr<对端uid>` 旧标准命名，**本端并未订阅该话题**）
|
||
|
||
而不是
|
||
|
||
- ✅ `p2pv97xq86jw3ceeTCfxVJ8pw`（服务端自己在 `me` 的 `meta sub` 里下发、并在 `friend.request.accepted` 的 `payload.topic` 里给出的**真正会话**）。
|
||
|
||
同一时刻服务端还把**同一条逻辑消息**（同 `ts`、同 `seq=17`）写进了 `p2p...` 话题，形成**双写**。
|
||
|
||
结果：客户端本地同一好友出现**两条单聊会话**，导致用户可见的两个问题：
|
||
|
||
1. 会话行的 `usr<uid>` 那条没有服务端下发的 `acs` → `isJoiner == false` → 客户端在会话行右下角显示出 `nosign`（🚫）禁止图标；
|
||
2. 客户端会话列表去重逻辑保留 `usr<uid>`、隐藏 `p2p...` → **对方的后续消息与未读数都不更新**（未读还被从总数里扣掉，"消息"Tab 角标偏小）。
|
||
|
||
---
|
||
|
||
## 2. 时间线（取证端 = 通过人本人 B，2026-09-13）
|
||
|
||
| 时间（UTC） | 事件 |
|
||
| --- | --- |
|
||
| 06:13:39 | B（echarles5）删除好友 A（charles1），双方关系解除（A 端收到 `friend.deleted`） |
|
||
| 06:27:09.610 | A 申请、B 通过；服务端下发 `friend_added` 系统提示，**同时写入 `usrHnkwn8VSfKc`（seq 17）与 `p2pv97xq86jw3ceeTCfxVJ8pw`（seq 17）** |
|
||
| 06:27:09.594 | `GET /v1/im/friends` 返回 A 的会话 `topic = p2pv97xq86jw3ceeTCfxVJ8pw` |
|
||
| 06:27:10.367 | `POST /v1/im/conversations/p2p {"peer_user_id":"usrHnkwn8VSfKc"}` 返回 `topic = p2pv97xq86jw3ceeTCfxVJ8pw` |
|
||
| 06:27:11.070 | `me` 的 `meta sub` 只下发 `p2pv97xq86jw3ceeTCfxVJ8pw`（订阅 `acs=JRWPA`、`priv.peer=usrHnkwn8VSfKc`），**没有 `usrHnkwn8VSfKc`** |
|
||
| 06:27:32.089 | A 发送消息 `a`，落在 `p2pv97xq86jw3ceeTCfxVJ8pw` seq 18 |
|
||
|
||
---
|
||
|
||
## 3. 服务端下行报文（原文）
|
||
|
||
### 3.1 系统提示被实时投递到旧命名话题（本端未订阅）
|
||
|
||
```json
|
||
{
|
||
"data": {
|
||
"topic": "usrHnkwn8VSfKc",
|
||
"ts": "2026-09-13T06:27:09.61Z",
|
||
"seq": 17,
|
||
"head": {
|
||
"x-im-from": "system",
|
||
"x-im-schema": 1,
|
||
"x-im-template": "friend_added",
|
||
"x-im-type": "system_notice"
|
||
},
|
||
"content": {
|
||
"actors": [
|
||
{ "user_id": "usrv97xq86jw3c", "click": { "target_id": "usrv97xq86jw3c", "type": "user_profile" } },
|
||
{ "user_id": "usrHnkwn8VSfKc", "click": { "target_id": "usrHnkwn8VSfKc", "type": "user_profile" } }
|
||
],
|
||
"extra": { "request_id": "frq_OYo72xKkkgU" },
|
||
"level": "normal",
|
||
"template": "friend_added",
|
||
"text": "你们已成为好友，现在可以开始聊天了。"
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
客户端侧随即落库并回执（说明客户端把它当作**合法会话消息**处理）：
|
||
|
||
```text
|
||
SqlStore - msgReceived：来自话题 payload usrHnkwn8VSfKc，topicId=9，userId=3，seq=17
|
||
出站[回执(note)] {"note":{"what":"recv","topic":"usrHnkwn8VSfKc","seq":17}}
|
||
入站[在线状态(pres)] {"pres":{"topic":"me","src":"usrHnkwn8VSfKc","what":"msg","seq":17}}
|
||
```
|
||
|
||
### 3.2 同一条消息也被写进真会话（双写证据）
|
||
|
||
随后客户端订阅真会话拉历史，拿到**同 `ts`、同 `seq`** 的同一条提示：
|
||
|
||
```json
|
||
{
|
||
"data": {
|
||
"topic": "p2pv97xq86jw3ceeTCfxVJ8pw",
|
||
"ts": "2026-09-13T06:27:09.61Z",
|
||
"seq": 17,
|
||
"head": { "x-im-from": "system", "x-im-schema": 1, "x-im-template": "friend_added", "x-im-type": "system_notice" },
|
||
"content": { "template": "friend_added", "text": "你们已成为好友，现在可以开始聊天了。", "...": "与上一条 content 完全一致" }
|
||
}
|
||
}
|
||
```
|
||
|
||
```text
|
||
SqlStore - msgReceived：来自话题 payload p2pv97xq86jw3ceeTCfxVJ8pw，topicId=11，userId=3，seq=17
|
||
```
|
||
|
||
> 同一 `ts` + 同一 `seq=17` 出现在两个 topic ⇒ 服务端对该提示**写了两份**。
|
||
> 本地 `topicId`：`usrHnkwn8VSfKc = 9`、`p2pv97xq86jw3ceeTCfxVJ8pw = 11` —— 旧命名话题**更早存在**，本轮关系重建后并未被撤销或合并。
|
||
|
||
### 3.3 服务端自己只承认 `p2p...`（`me` 的 `meta sub`）
|
||
|
||
```json
|
||
{
|
||
"meta": {
|
||
"id": "115975",
|
||
"topic": "me",
|
||
"ts": "2026-09-13T06:27:32.444Z",
|
||
"sub": [
|
||
{
|
||
"updated": "2026-09-13T06:27:11.07Z",
|
||
"online": true,
|
||
"acs": { "want": "JRWPA", "given": "JRWPA", "mode": "JRWPA" },
|
||
"public": {
|
||
"avatar_file_id": "ZrI4Fut4heE.jpg",
|
||
"display_name": "charles1",
|
||
"fn": "charles1",
|
||
"name": "charles1",
|
||
"nickname": "charles1",
|
||
"public_account": "usrHnkwn8VSfKc"
|
||
},
|
||
"private": { "created_by": "http", "peer": "usrHnkwn8VSfKc" },
|
||
"topic": "p2pv97xq86jw3ceeTCfxVJ8pw",
|
||
"touched": "2026-09-13T06:27:32.089Z",
|
||
"seq": 18
|
||
}
|
||
]
|
||
}
|
||
}
|
||
```
|
||
|
||
> `sub` 数组里**只有** `p2pv97xq86jw3ceeTCfxVJ8pw`。服务端却把 `{data}` 投到了 `usrHnkwn8VSfKc` —— 这是一个**本端从未订阅**的话题。
|
||
|
||
### 3.4 业务事件与 HTTP 接口都指向 `p2p...`
|
||
|
||
```json
|
||
{"info":{"topic":"usrv97xq86jw3c","from":"usrHnkwn8VSfKc","what":"im","event":"friend.request.accepted",
|
||
"payload":{"topic":"p2pv97xq86jw3ceeTCfxVJ8pw","user_id":"usrHnkwn8VSfKc","request_id":"frq_OYo72xKkkgU"}}}
|
||
```
|
||
|
||
```json
|
||
{"user_id":"usrHnkwn8VSfKc","display_name":"charles1","relationship":"friend",
|
||
"topic":"p2pv97xq86jw3ceeTCfxVJ8pw","avatar_file_id":"ZrI4Fut4heE.jpg"}
|
||
```
|
||
|
||
> `friend.request.accepted` 的 `payload.topic`、`GET /v1/im/friends` 的 `topic`、`POST /v1/im/conversations/p2p` 的响应都明确是 `p2pv97xq86jw3ceeTCfxVJ8pw`。
|
||
> 说明服务端**知道**该会话的真实 topic，但系统提示仍写到了 `usr<uid>`。
|
||
|
||
---
|
||
|
||
## 4. 与接口文档契约的冲突
|
||
|
||
| 文档位置 | 约定 | 实际 |
|
||
| --- | --- | --- |
|
||
| 《IM-前后端对接文档》0.5.4.3.1（约 330 行） | "会话内系统消息**必须进入对应 P2P 或群 Topic 的消息流**，占用 `seq`" | `friend_added` 同时进入 `usr<uid>`（非对应会话） |
|
||
| 同章 `system_notice` 下行示例（约 337 行） | `{"data":{"topic":"p2p...", ... "x-im-template":"friend_added" ...}}` | 实际 `"topic":"usrHnkwn8VSfKc"` |
|
||
| 同文档 3.5（约 1108 行） | 好友申请通过后服务端"在同一事务内建立双方关系和 **P2P 订阅**" | 建立了 `p2p...` 订阅，但旧 `usr<uid>` topic/订阅仍在，且系统提示写到旧 topic |
|
||
| 同文档 `GET /v1/im/friends`（约 1564 行） | 好友的会话 `topic` 为 `p2p...` | 一致 ✅（正因如此客户端更无法理解 `usr<uid>` 上的消息） |
|
||
|
||
---
|
||
|
||
## 5. 对客户端的影响（为什么客户端只能兜、不能治）
|
||
|
||
1. **会话列表出现两条同一好友的会话**，去重只能靠启发式规则（按对端 uid 分组打分）择一保留；
|
||
2. **保留错的那条就丢消息/未读**：旧命名话题 `acs` 为空（`isJoiner == false`）但本地已落库消息，客户端历史上"标准命名优先"的规则会保留它、隐藏真会话 → 用户看到会话不更新；
|
||
3. **误显示禁止图标**：`acs` 为空时客户端无法区分"未同步"与"已不是成员"，会在会话行右下角画 `nosign`（🚫）；
|
||
4. **历史数据永久分裂**：已有一批用户的本地历史落在 `usr<uid>`，服务端新会话在 `p2p...`，客户端无法自动合并；
|
||
5. 客户端对**未订阅**话题收到的 `{data}` 只能被动落库（已回执 `recv`），无法判断该不该收。
|
||
|
||
---
|
||
|
||
## 6. 需要后端确认 / 处理
|
||
|
||
1. **`friend_added` 等会话内系统提示为什么写到 `usr<uid>`？**
|
||
请改为只写**会话 topic**（当前为 `p2p...`），与 `payload.topic` / `GET /friends` 的 `topic` 保持一致。
|
||
2. **同一对好友为什么存在两套 Topic + 两份订阅？**
|
||
重装/删好友/重新加好友后，旧的 `usr<uid>` topic 与订阅应当被撤销或合并；
|
||
当前 `usrHnkwn8VSfKc`（本端 uid 维度）与 `p2pv97xq86jw3ceeTCfxVJ8pw` 同时存在，且系统提示双写。
|
||
3. **`{data}` 投递到未在 `me` 的 `meta sub` 里的话题是否预期？**
|
||
若不是，请修投递；若是（设计如此），请在文档里明确 `usr<uid>` 仍是合法会话名，并同步在 `meta sub` 里下发它的 `acs`/`seq`/`pub`，否则客户端无法正确渲染。
|
||
4. **是否可以把单聊统一收敛到 `p2p...`**，并提供旧 `usr<uid>` 历史消息的迁移/合并方案（客户端愿意配合按话题重定向）。
|
||
5. **（附带，需确认口径）** `friend.request.accepted` 的 `payload.user_id` 与文档不一致：
|
||
文档写 `payload:{"user_id":"usr_actor"}`（通过人），实测该帧在**通过人本人**设备上 `from` 和 `payload.user_id` 都是**申请人** `usrHnkwn8VSfKc`。客户端目前已按"`payload.user_id` = 对方"消费（用于刷新会话 context、反查会话），若后端要改回文档口径请提前同步。
|
||
|
||
---
|
||
|
||
## 7. 复现步骤
|
||
|
||
### 前置
|
||
- 账号 A：`usrHnkwn8VSfKc`（charles1），账号 B：`usrv97xq86jw3c`（echarles5），两台设备/两个模拟器分别登录；
|
||
- 两端都开启 Debug 日志（会打印 `入站[消息数据(data)]` 与 `SqlStore - msgReceived`）。
|
||
|
||
### 步骤
|
||
1. **先制造"旧命名话题"残留**：B 删除 A 好友（B 端：聊天 → A 的会话 → 右上角设置 → 「删除好友」，确认删除）。
|
||
- 预期：A 端收到 `{"info":{"...","event":"friend.deleted","payload":{"user_id":"usrv97xq86jw3c"}}}`。
|
||
- 此时 B 端本地已存在旧命名话题 `usr<A的uid>`（本次取证中为 `usrHnkwn8VSfKc`）。
|
||
2. A 向 B 发起好友申请（A 端：添加好友 → 搜索 `echarles5` → 发送申请）。
|
||
3. B 通过好友申请（B 端：通讯录 → 新的朋友 → 通过）。
|
||
4. **观察 B 端日志**，应能复现：
|
||
```text
|
||
入站[消息数据(data)] {"data":{"topic":"usrHnkwn8VSfKc","seq":17,"head":{"x-im-template":"friend_added","x-im-type":"system_notice"},...}}
|
||
SqlStore - msgReceived：来自话题 payload usrHnkwn8VSfKc，topicId=9，userId=3，seq=17
|
||
入站[在线状态(pres)] {"pres":{"topic":"me","src":"usrHnkwn8VSfKc","what":"msg","seq":17}}
|
||
```
|
||
随后拉真会话历史时，同 `ts`/`seq` 的提示又出现在 `p2pv97xq86jw3ceeTCfxVJ8pw`；
|
||
并且 `me` 的 `{meta sub}` 里**只有** `p2pv97xq86jw3ceeTCfxVJ8pw`。
|
||
5. **观察 B 端界面**：会话列表里 A 的那一行副标题是"你们已成为好友，现在可以开始聊天了。"，右下角带 🚫 图标。
|
||
6. A 再发一条消息（如 `a`）→ B 端该会话行**副标题与未读数都不更新**（消息实际落在 `p2pv97xq86jw3ceeTCfxVJ8pw`，被去重隐藏）。
|
||
7. **服务端核对**：`topics` 表应能查到同一对好友的两行
|
||
（`usrHnkwn8VSfKc` 与 `p2pv97xq86jw3ceeTCfxVJ8pw`），以及双方的订阅记录；`messages` 表里 `friend_added` 在两个话题下各有一条（同 `ts`、同 `seq`）。
|
||
|
||
### 最小验证（不依赖"先删好友"这段历史）
|
||
让 A 申请、B 通过，直接核对服务端把 `friend_added` 写到了哪个 topic：若仍是 `usr<A的uid>`，即复现本问题（第 1 步只是让残留话题必然存在，便于稳定复现）。
|
||
|
||
---
|
||
|
||
## 8. 验收标准
|
||
|
||
1. 好友申请通过后，`friend_added` **只**下发到会话 topic（当前为 `p2p...`），且该 topic 出现在 `me` 的 `meta sub` 中；`usr<uid>` 上不再出现任何消息；
|
||
2. `me` 的 `meta sub` 中同一对好友**只有一个** P2P topic、一份订阅；历史遗留的 `usr<uid>` topic/订阅被撤销或合并；
|
||
3. 对不存在的会话不再有"投递到未订阅话题"的 `{data}`（或按文档补齐该话题的 `meta sub`）；
|
||
4. 客户端表现（不依赖本轮客户端兜底）：B 端会话列表只出现**一行** A 的会话，副标题为最新消息、未读角标正确、**无 🚫 图标**；A 端同理。
|
||
|
||
---
|
||
|
||
## 9. 客户端已做的兜底（不依赖后端修复，但不能替代后端修）
|
||
|
||
1. `Utils.duplicateP2PTopicNames` 改为**按对端 uid 分组 + 打分择一保留**
|
||
（本地有消息 8 > 仍是成员 `isJoiner` 4 > 标准命名 2 > 有 `priv.peer` 1），
|
||
让"有消息且在关系内"的 `p2p...` 真会话优先，同时保留"有历史优先"以免去重丢消息；
|
||
2. `ChatListViewCell` 的禁止图标改为**仅在确认服务端下发过 `acs.mode` 且确非成员**时显示
|
||
（`acs` 未同步不再误画 🚫）；
|
||
3. 会话列表过滤对"本地已有消息但 `acs` 未下发"的单聊放宽（`isLocalKnownP2PConversation`），
|
||
保证"有消息就一定有会话行"。
|
||
|
||
> 以上兜底只解决"显示哪一条、图标对不对"。**系统提示被写进隐藏话题、历史分裂在两个 topic** 这两点必须后端收敛后才能根治。
|