524 lines
42 KiB
Markdown
524 lines
42 KiB
Markdown
# IM 后端问题清单
|
||
|
||
_2026-09-14 全面复核：本次对现有33条逐条重新核实（能实测的实测，能读代码的读代码，均标注核实方式），并把此前散落在各处（`docs/IM-后端问题清单-2026-09-04.md`、历次前端重写工程记录）但从未收录进本清单的问题一并归档，同时确认了几条此前记录、后来查明其实是前端自己的bug（已在下方"已排除"列出，不再作为后端问题）。这次复核期间发现后端正在把数据库从单机MySQL迁移到新k3s集群的Percona XtraDB Cluster（PXC）——`server/meetingim.conf`/`tinode.conf`的MySQL/Redis/Kafka地址已经从旧VM改成新集群地址，代码里也新增了专门处理PXC兼容性问题（命名锁、自增ID越界）的分支——这是今天新发现的几个MySQL相关问题（尤其是周期性的驱动层连接损坏）很可能与之相关的重要背景，供后续排查参考。_
|
||
|
||
## 目录
|
||
|
||
**P0 · 安全漏洞 / 核心功能完全不可用**
|
||
|
||
暂无。
|
||
|
||
**P1 · 数据完整性 / 权限失效 / 主要功能缺陷**
|
||
|
||
| 编号 | 接口 | 一句话 |
|
||
|---|---|---|
|
||
| [问题36](#问题36) | `POST /messages/forward` | 并发转发下响应说"失败"其实已经真实写入——2026-09-14用干净的12并发复测，仍有2/3的"失败"响应对应真实落库的消息，最近一次代码改动（`926b4bb`）改善了部分逻辑但未解决根本问题 |
|
||
| [新增80](#新增80) | Bearer Token鉴权（影响所有需要登录态的接口） | 同一个token并发请求，20-45%概率随机返回401 AUTH_REQUIRED，鉴权层把"token真无效"和"Redis/DB瞬时报错"统一处理成同一个错误码且完全不打日志，无法从现有日志区分具体原因 |
|
||
| [新增81](#新增81) | `GET /v0/file/s/{id}`（媒体文件服务） | 查询数据库里不存在的列`mtg.recorder_user_id`，25分钟观测窗口内命中这条SQL的请求243次全部失败 |
|
||
|
||
**P2 · 数据一致性 / 体验缺口 / 校验缺失**
|
||
|
||
| 编号 | 接口 | 一句话 |
|
||
|---|---|---|
|
||
| [问题25](#问题25) | `POST /messages/forward`、`/favorites/forward` | 带附言转发时 `head` 声明类型与 `content` 实际结构对不上 |
|
||
| [问题27](#问题27) | `GET /reports/daily` | `status` 参数不做取值校验，传任何值都返回200+空列表 |
|
||
| [问题30](#问题30) | `GET /system-notifications` | `summary`/`action`结构不一致，且会议响应事件被写成两条重复通知 |
|
||
| [问题33](#问题33) | `GET /reports/daily` | `permissions` 四个字段恒为同一组硬编码值，与用户/参数无关 |
|
||
| [问题35](#问题35) | `GET /users/{id}/profile` | 设了备注之后拿不到对方的原昵称（`GET /friends`一侧已修复） |
|
||
| [新增3](#新增3) | `PATCH /conversations/{topic}/settings` | 单聊置顶没有批量查询接口，会话列表永远看不出置顶效果 |
|
||
| [新增8](#新增8) | `GET /friends` | 完全不感知拉黑关系，与另外两个接口表现不一致 |
|
||
| [新增15](#新增15) | `POST /meetings/{id}/cancel` | 完全不校验 `version`，乐观锁摆设 |
|
||
| [新增24](#新增24) | `GET /groups/{topic}`、`/settings` | 群成员数存在两套互相独立、可永久失配的计数器 |
|
||
| [新增25](#新增25) | 原生WS `{pub}` | link类型消息协议层可构造，但没有真实用户可从UI触达的发送路径 |
|
||
| [新增30](#新增30) | `GET /settings/youth-mode` | 开启后不对任何功能做实际限制，`enforced` 恒为硬编码false（前端已移除此功能，仅保留记录完整性） |
|
||
| [新增31](#新增31) | `POST /reports/abuse` | 不校验 `requires_description`，可对必填原因提交空描述 |
|
||
| [新增32](#新增32) | `POST /system-notifications/{id}/read` | 对已读通知重复标记，响应回显请求值但真实存储值不变 |
|
||
| [新增34](#新增34) | `POST /tenant-applications` | 统一社会信用代码无去重机制，可无限重复提交 |
|
||
| [新增41](#新增41) | `POST /groups/{topic}/mutes` | 无角色层级保护，管理员可禁言群主、任何角色可自我禁言 |
|
||
| [新增47](#新增47) | `POST /v0/file/u/` | 真实文件上传上限是32MB而非声明的100MB，且从未用于前端预校验 |
|
||
| [新增49](#新增49) | `POST /reports/daily`、`/monthly` | 创建接口对日期只校验格式不校验范围，年份0000/2099均可创建 |
|
||
| [新增51](#新增51) | `POST /meetings` | 不校验 `attendee_user_ids` 是否真实存在，可创建任意规模"幽灵参会人" |
|
||
| [新增54](#新增54) | 日报/月报SUBMIT | 不校验必填内容，可提交完全空白报告 |
|
||
| [新增56](#新增56) | `POST /settings/youth-mode/enable` | `policy_version` 不做版本校验，传任意值即被无条件接受（前端已移除此功能） |
|
||
| [新增76](#新增76) | `GET /app/releases/latest?platform=web` | `platform` 只接受ios/android，web端完全不支持检查更新 |
|
||
| [新增77](#新增77) | `GET /groups/{topic}/announcements/latest` | 响应没有已读人数字段，"已读N/M"这个设计要求的功能无法实现 |
|
||
| [新增78](#新增78) | `GET /topics/{topic}/messages/search`、收藏/通话记录的相关字段 | 发送者/对方user_id被裁掉`usr`前缀，或返回内部hash而非可寻址id |
|
||
| [新增82](#新增82) | `cache group settings`（内部缓存，影响群相关读接口的性能与正确性） | 群设置缓存反序列化失败，高频出现（242次/25分钟），覆盖大量不同群 |
|
||
| [新增83](#新增83) | `media serve`（文件服务） | 死锁（1213/40001）没有捕获重试，命中的请求直接失败 |
|
||
| [新增84](#新增84) | 内部后台任务"media gc" | 周期性（约每50秒一次）触发MySQL驱动层连接损坏（"busy buffer"/协议序号错乱），与PXC迁移的时间点吻合，怀疑相关 |
|
||
| [新增85](#新增85) | `GET /groups/{topic}/members?role=admin` 等按查询参数区分的缓存 | 写操作（如提升管理员）后，特定查询参数组合的结果有90秒以上的缓存滞后 |
|
||
| [新增86](#新增86) | `GET /calls` | 响应字段结构与协议文档完全不同（无`peer`对象、无`incoming`布尔值、时间戳拆成4个字段、`topic`是内部hash） |
|
||
| [新增87](#新增87) | 群二维码 `POST /groups/{topic}/qrcodes` vs `POST /qrcodes/resolve` | 铸造接口用`group_snapshot`字段名，解析接口对同样的数据用`group`字段名，两个接口不一致；解析接口另有一个协议文档完全没提过的`status`字段 |
|
||
| [新增88](#新增88) | `GET /topics/{topic}/messages/search` | 部分明显应该命中的关键词搜索返回空结果（搜索召回不稳定，2026-09-14复测比更早的记录有改善但未完全解决） |
|
||
| [新增89](#新增89) | `im_file_review_tasks` / 养成动态图片审核 | IM 仅创建文件审核任务，没有执行 Worker，所有带图动态都会永久停在 `reviewing/pending` |
|
||
| （无编号，功能缺口非bug） | 无 | 整份协议文档没有"移出/踢出群成员"这个操作，`03-group.dc.html`里"移出"按钮因此没有对应接口可用——确认是协议本身没设计这个功能，不是遗漏 |
|
||
| （无编号，可能是设计而非缺口） | 无 | 无手机号查询/换绑接口、无登录设备列表接口；`POST /security/challenges`这个"敏感操作二次验证"机制目前只服务青少年模式两个场景，没有覆盖改密码等场景 |
|
||
|
||
---
|
||
|
||
## 本次复核确认已修复（不再是问题，供归档参考）
|
||
|
||
以下条目在2026-09-14用真实账号实测或直接读当前代码确认已经修复，从清单中移除：
|
||
|
||
- **问题22**（无登出/Token撤销接口）：**已修复**。`POST /v1/im/auth/logout`现在是真实可用的接口（之前误判404的路径是没有走对，正确路径是这个）。实测：新token连续3次200 → 调用logout返回200 → 同一token之后5次全部401，确认真实吊销，不是假成功。
|
||
- **问题28**（`purpose=user_avatar`被拒）：**已修复**。实测提交真实PNG文件，200成功。
|
||
- **新增16**（总经理信箱超长内容返回500）：**已修复**。代码确认`serveIMExecutiveMailboxSubmissions`现在显式捕获`ErrPolicy`并返回400 VALIDATION_FAILED，不再落到default的500分支。
|
||
- **新增17**（`writeIMRelationError`把`ErrNotFound`错误映射成`MALFORMED_REQUEST`）：**已修复**。代码确认现在`ErrNotFound`正确映射到404+`RESOURCE_NOT_FOUND`，reason与message一致。
|
||
- **新增27**（工作台`unread_count`恒为0）：**已修复**（2026-09-10记录"只接入bootstrap，workbench本身还没接"，现在确认`serveIMWorkbench`内部也调用了`populateWorkbenchModuleUnreadCounts`）。注：目前只有"会议"模块会计算真实值，其余模块代码上仍是原始SQL的0值，但这正好是原始bug报告实测覆盖的场景，已修复。
|
||
- **新增42**（群公告按id查询恒定返回最新公告）：**已修复**。代码确认现在正确解析路径里的`announcement_id`并调用`GetAnnouncement`按id查询，不再无视这个参数。
|
||
- **新增43**（群文件登记接口无长度/存在性校验）：**已修复**。代码确认现在对`file_name`(255)/`mime_type`(128)做长度校验，对`file_size`做负数校验，且会调用`store.Files.Get`验证`file_id`真实存在。
|
||
- **新增45**（收藏/搜索/宫格分页off-by-one永久丢失边界记录）：**已修复**。实测：24条真实收藏，用limit=10分3页拉取（10+10+4），合并后24条一条不少、无重复。
|
||
|
||
## 本次复核确认仍是历史误判（从未是真正的后端bug，不应再作为后端问题提出）
|
||
|
||
以下条目此前曾被记录为"疑似后端bug"，后来（多为9月上中旬的复核）证实其实是前端自己调用错了接口/传错了参数，backend行为一直是对的——**不要把这几条再当成后端问题反馈**：
|
||
|
||
- `GET .../groups/{topic}/members/{user_id}/profile` 查自己恒定400——真相：有专门的`members/me/profile`接口可以正确查询，前端读操作一直在用错误的通用by-id接口，写操作反而一直用对了。已切换到正确接口，问题消失。
|
||
- `POST .../groups/{topic}/mutes/batch` 恒定405——真相：真实的批量禁言接口是`/mutes`（不带`/batch`后缀），前端一直在调一个不存在的路径。已改用正确路径。
|
||
- `GET /users/{id}/profile` 对好友`usrW9ijv236hHA`恒定403——真相：响应体里其实带着`message:"profile is private"`，是对方自己设置了资料保护，属于设计内行为，不是bug。
|
||
- `PATCH .../groups/{topic}/member-settings`（置顶/免打扰）恒定400——真相：这个接口的请求体结构里根本没有`version`字段，后端解码器对未声明字段严格拒绝；前端一直在照抄别的接口的乐观锁写法多传了一个`version`字段。已去掉，问题消失。
|
||
- 群设置`governance`字段"被后端写死成默认值"——这是一次静态代码审查的猜测，当场用真实接口交叉验证后证明是错的：`/settings`和`/governance`返回一致，写入后能正确反映在读接口上。从未真正成立过。
|
||
|
||
---
|
||
|
||
<a id="问题36"></a>
|
||
## 问题 36（P1，2026-09-14复测：仍未修复，最近一次代码改动效果有限）：并发转发到同一个会话时，响应说"失败"的条目里相当一部分其实已经成功写入，重试会造成真实内容重复
|
||
|
||
**证据强度**：✅ 实测确认（多轮独立复现，含2026-09-14最新一轮干净复测）+代码确认
|
||
|
||
**2026-09-14复测方法与结果**：`git pull`确认`server/kafka_message_persist.go`在9月11日有过一次专门的修复提交（`926b4bb fix im forwarding and message list regressions`），代码上看这次改动新增了`Pending`状态（区分"确定成功"/"确定失败"/"不确定，可能已经发出"三种情况，而不是原来的非成功即失败）。但不能只信代码改动就下结论，实际用真实群（`grpDclMebv3MuI`）、真实消息（seq 135）做了一次干净的12并发转发测试（每个请求用独立的幂等键，模拟"用户看到失败提示后重新点击"的真实场景）：
|
||
- 12个请求里7个报告"sent"成功（seq 136/137/138/139/140/142/143），3个报告"failed"（`INTERNAL_ERROR`），2个命中已知的401鉴权问题（新增80，未到达转发逻辑）。
|
||
- 测试前群里搜索"测试"能查到的最大seq是135；测试后变成130-144连续9个新seq（136-144）。
|
||
- **9个真实新消息 vs 7个确认成功——多出来的136-144里的141和144，对应的正是那3条报"failed"里的2条,它们实际上真的写入成功了,只是响应告诉客户端"失败"。**
|
||
|
||
**结论**：本质问题没有解决——响应仍然不可信，"failed"不能被客户端安全地当作"真的没发生"来处理，重试依然会造成真实重复。9月11日的那次改动可能改善了部分场景（比如更细粒度的pending状态跟踪），但没有堵住这个具体的漏洞。
|
||
|
||
**根因**（此前已逐行核对，本次未见改变）：开启Kafka时，`saveMessageMaybeKafka`先原子预留seq，再异步把消息发布到Kafka——如果produce调用本身报错（例如含糊的ack超时），HTTP handler判定失败并返回给客户端，但已预留的seq和可能已经在网络层提交成功、只是没收到ack的Kafka消息都回滚不了，只要Kafka消费者最终异步写入，"失败"响应背后就会真实落库。
|
||
|
||
**接口**：`POST /v1/im/messages/forward`
|
||
|
||
**前端现状**：批量转发的失败提示照原样展示后端返回的`status`/`reason`，无法感知也无法规避"响应可能撒谎"这个问题，需要后端修正响应准确性（例如：明确区分"确定失败可安全重试"和"结果不确定，建议先检查再决定是否重试"两种状态，而不是都归为同一种"failed"）。
|
||
|
||
---
|
||
|
||
<a id="新增80"></a>
|
||
## 新增 80（P1，2026-09-14新发现）：Bearer Token鉴权在并发请求下随机出现401，且无法从日志定位具体原因
|
||
|
||
**证据强度**：✅ 实测确认（自己独立复现，两个不同接口各自独立测试）+代码确认（完整调用链，含具体文件行号）
|
||
|
||
**现象**：用同一个有效token对`GET /v1/im/groups/{topic}`或`GET /v1/im/me`连续发起20个并发请求，大约15%-65%会随机返回`401 {"code":30043,"reason":"AUTH_REQUIRED"}`，比例不稳定（同一token连续测两轮，一轮5/20失败，几秒后另一轮13/20失败）。对照组：同样并发打`POST /v1/im/tenants/resolve`（只需要API Key，不需要bearer token）20/20全部成功，证明问题只出在bearer token鉴权这一层，不是网络或网关层面的问题。
|
||
|
||
**排除的可能性**：进入当前所有正在运行的3个`im-server` Pod内部，对`AUTH_TOKEN_KEY`/`MYSQL_DSN`/`REDIS_ADDR`/`REDIS_PASSWORD`/`TENANT_REGISTRY_DB`/`API_KEY_SALT`/`UID_ENCRYPTION_KEY`共7个关键配置项，在每个Pod自己进程内部单独计算哈希值做比对（不在外部解密Secret），3个Pod完全一致——排除"多实例配置不一致"这个最初怀疑的方向；3个Pod是同一批次创建、同一个ReplicaSet，没有游离的旧实例。
|
||
|
||
**根因（读当前`im_be`源码确认，文件行号）**：`GET /v1/im/groups/{topic}`等接口的鉴权链条是 `authenticateIMHTTPBearer`(`server/im_http.go:7093`) → `resolveIMHTTPBearerToken`(`server/im_http.go:7111`) → `(*authenticator).Authenticate`(`server/auth/token/auth_token.go:103`)。这个函数内部，token签名错误、过期、`serial_num`不匹配、Redis撤销状态查询报错(`IsLoginTokenRevoked`)、按租户路由的DB鉴权版本号查询报错(`GetAuthVersion`/`TenantAdapterFor`)——**所有这些情况的错误全部被统一转换成同一个`types.ErrPermissionDenied`**，最终一律报401，且**这条失败路径上完全没有任何日志输出**，导致即使线上真实发生了这类失败，事后也无法从日志区分具体是哪一种原因触发的。
|
||
|
||
其中`GetAuthVersion`背后的`TenantAdapterFor`(`server/db/mysql/adapter.go:469`)使用**每个进程自己独立维护的懒加载租户连接缓存**，某个租户如果还没被当前进程缓存过，一波并发请求会各自独立地去开一条新数据库连接并`Ping()`，这种"并发抢着建连接"的场景比"某个pod配置固定错误"更能解释"20个并发里随机几个失败、且失败比例还会波动"这个现象。
|
||
|
||
**支持证据**：查了同一时间窗口的k8s事件，3个pod中有2个在过去1小时内真实触发过健康检查失败（`Unhealthy: context deadline exceeded`，探测超时只给了1秒）；同时机器上2/3节点内存占用在69%-81%（这是个多个服务共享的测试集群）。另外，MySQL的`aborted_connects`计数器非零（13），跟"存在瞬时连接失败"这个方向一致，但不是决定性证据。
|
||
|
||
**重要背景**：这次复核时发现后端仓库刚经历一次数据库基础设施迁移——`server/meetingim.conf`/`tinode.conf`里的MySQL/Redis/Kafka地址从旧VM换成了新k3s集群的PXC（Percona XtraDB Cluster）地址，且代码里新增了`isPXCStrictModeNamedLockError`/`isIDOutOfRange`两个专门处理PXC兼容性问题的错误分支，说明这个迁移目前还在持续排查兼容性问题的阶段。这个401问题的时间点与这次迁移吻合，虽然鉴权代码本身没有直接调用命名锁，但不排除是同一次基础设施变动带来的连锁不稳定，建议后端一并排查。
|
||
|
||
**接口**：影响所有需要bearer token鉴权的接口（穷举测试了`GET /v1/im/groups/{topic}`、`GET /v1/im/me`两个，机制上应该影响全部同类接口）
|
||
|
||
**给后端的建议**：（1）在这条失败路径上补充日志，区分"token确实无效"和"内部依赖（Redis/DB）报错"两种情况，不要两者都报同一个401；（2）审视`TenantAdapterFor`懒加载连接的并发安全性，避免同一租户的并发请求各自重复建连接。
|
||
|
||
---
|
||
|
||
<a id="新增81"></a>
|
||
## 新增 81（P1，2026-09-14新发现）：文件服务查询数据库里不存在的列，几乎每次命中都失败
|
||
|
||
**证据强度**：✅ 实测确认（真实运行日志，25分钟窗口内3个pod合计243次）
|
||
|
||
**现象**：`media serve`（文件服务，`/v0/file/s/{id}`）报错`Error 1054 (42S22): Unknown column 'mtg.recorder_user_id' in 'where clause'`，25分钟的观测窗口里3个pod合计出现243次，是这次复核发现的所有问题里频率最高的一个——几乎所有命中这条SQL路径的真实请求都会失败。
|
||
|
||
**推测**：列名前缀`mtg`大概率是"会议(meeting)"相关表，可能是代码引用了一个数据库里还不存在的列（缺一次迁移），也可能是列名本身写错了。不确定具体原因，需要后端自己确认。
|
||
|
||
**接口**：`GET /v0/file/s/{id}`（原生Tinode大文件下载，命中会议关联文件时）
|
||
|
||
**基础设施侧的态度**：这类"代码查询数据库结构对不上"的问题，本身可能是缺一次迁移，但我们不建议自己去手动改数据库列（不清楚正确的类型/默认值/是否有对应的后端代码逻辑依赖这个列的具体语义），必须由后端确认。
|
||
|
||
---
|
||
|
||
<a id="问题25"></a>
|
||
## 问题 25（P2，最常见路径已修故降级）：带附言转发/收藏转发时，`head` 声明的类型与 `content` 的实际结构对不上
|
||
|
||
**证据强度**：✅ 实测确认（四条路径全部真实构造验证）
|
||
|
||
**现象**：逐条转发带附言、收藏转发带附言两条路径，`head`仍声明原消息类型（如image/text），但`content`换成`{forwarded,comment,snapshot}`等包装对象，客户端按head类型解析content会得到空白/无效内容。逐条转发不带附言这条最常见路径已经修好（content原样透传）。
|
||
|
||
**期望**：附言作为独立的一条文本消息发送（对接文档本来就是这么描述的），转发的那条消息仍然原样透传原content。
|
||
|
||
**接口**：`POST /v1/im/messages/forward`；`POST /v1/im/favorites/forward`
|
||
|
||
---
|
||
|
||
<a id="问题27"></a>
|
||
## 问题 27（P2）：`status` 参数不做取值校验，传任何值都返回200+空列表
|
||
|
||
**证据强度**：✅ 实测确认（2026-09-14重测，传`status=totally_bogus_value_xyz`依然200+`items:[]`，未变）
|
||
|
||
**现象**：传完全不存在的status值也返回200，客户端无法区分"确实没数据"和"根本不支持"。
|
||
|
||
**接口**：`GET /v1/im/reports/daily?status=`（月报同构）
|
||
|
||
---
|
||
|
||
<a id="问题30"></a>
|
||
## 问题 30（P2）：系统通知的 `summary` 要么是空串、要么是机器码，`action` 的结构因来源而异，且会议响应事件会被写成两条重复通知
|
||
|
||
**证据强度**：✅ 实测确认（三种summary情况+两条重复通知具体案例）+代码确认（重复通知根因）
|
||
|
||
**现象**：`summary`有时空串、有时机器码（如`accepted`/`rejected`）、有时真实数据；`action`是自由结构，不同来源放的键完全不同；会议响应更新会被两条独立代码路径各写一条内容几乎相同、结构不同的重复通知。
|
||
|
||
**根因（重复通知）**：`serveIMMeetingRespond`同时调用受开关`imReliableHTTPEventsEnabled`控制的`publishIMMeetingEvent`（生成`{meeting_id}`形态）和无条件执行的`publishIMWorkbenchAndAudit`（经Kafka产生`{module,resource_id}`形态），该开关对标准请求头调用恒为true。
|
||
|
||
**接口**：`GET /v1/im/system-notifications`
|
||
|
||
**前端现状**：`summary`能在已知事件码表里查到就替换成中文，查不到就原样显示；跳转按钮按action里出现的键分派；重复通知没有做任何去重（不能安全启发式判断"内容相同就是重复"）。
|
||
|
||
---
|
||
|
||
<a id="问题33"></a>
|
||
## 问题 33（P2）：`permissions` 的四个字段在不同参数下恒为同一组值
|
||
|
||
**证据强度**：✅ 代码确认（2026-09-14重读源码，确认仍是硬编码map字面量，行号已随文件改动漂移到2614-2619行左右）
|
||
|
||
**现象**：`can_create`/`can_remind_unsubmitted`/`can_view_managed`/`makeup_allowed_days`换任何用户、scope、日期区间组合都恒为同一组值，因为响应体里这部分是Go代码写死的map字面量，完全不引用`principal`/`reports`/任何请求参数。
|
||
|
||
**接口**：`GET /v1/im/reports/daily`
|
||
|
||
---
|
||
|
||
<a id="问题35"></a>
|
||
## 问题 35（P2，`GET /friends`一侧已修复，范围收窄到`GET /users/{id}/profile`）：设了备注之后，好友主页详情接口拿不到对方的原昵称
|
||
|
||
**证据强度**：✅ 实测确认（2026-09-14再次复核，问题依然存在）
|
||
|
||
**现象**：`GET /v1/im/friends`响应里带的嵌套`peer`对象（`peer.display_name`）能正确带对方的真实原始昵称，这一侧的诉求已经满足。但`GET /v1/im/users/{id}/profile`依然没有修：既没有remark字段，也没有独立的原昵称字段——保存备注后本地乐观更新正确显示新备注，但一旦触发这个详情接口的背景刷新重新拉取，会因为接口不带remark字段而把显示"冲"回"未设置"，数据没有真的丢，只是这个详情页的显示会"看起来复原了"。
|
||
|
||
**接口**：`GET /v1/im/users/{id}/profile`（仍缺）；对照已修复的`GET /v1/im/friends`
|
||
|
||
**期望**：`GET /users/{id}/profile`比照`GET /friends`已经落地的`peer`对象模式，补上对方的真实原始昵称字段。
|
||
|
||
---
|
||
|
||
<a id="新增3"></a>
|
||
## 新增 3（P2）：单聊的"置顶聊天"没有任何办法让会话列表知道，因为没有批量查询会话设置的接口
|
||
|
||
**证据强度**：✅ 实测确认（对照群聊置顶排除法）
|
||
|
||
**现象**：群聊置顶写入订阅原生private字段能随meta同步下发；单聊置顶写入独立表且不写private字段，只有单条查询接口无批量接口，前端无法为几十上百个会话逐一查询，设置生效但用户看不出效果。
|
||
|
||
**接口**：`PATCH /v1/im/conversations/{topic}/settings`（写入）；缺失批量查询接口
|
||
|
||
---
|
||
|
||
<a id="新增8"></a>
|
||
## 新增 8（P2）：`GET /friends` 完全不感知拉黑关系，与另外两个接口表现不一致
|
||
|
||
**证据强度**：✅ 实测确认+代码确认
|
||
|
||
**现象**：拉黑后该好友仍显示`relationship:"friend"`且权限位全开，与`GET /conversations/{topic}/context`（正确显示`blocked_by_me`）、`GET /users/{id}/profile`（裸403）三者互不一致。
|
||
|
||
**根因**：`friendListItemPayload`及数据源`types.FriendListItem`从结构体到SQL全程未涉及黑名单表。
|
||
|
||
**接口**：`GET /v1/im/friends`；对照`GET /v1/im/users/{id}/profile`、`GET /v1/im/conversations/{topic}/context`
|
||
|
||
---
|
||
|
||
<a id="新增15"></a>
|
||
## 新增 15（P2）：`POST /meetings/{id}/cancel` 完全不校验 `version`
|
||
|
||
**证据强度**：✅ 实测确认+代码确认（2026-09-14重读源码，`serveIMMeetingCancel`依然只解析`Version int`但从未在调用`store.Meetings.Cancel`时传入这个字段）
|
||
|
||
**现象**：故意传`version:999`也直接成功，与同资源my-response接口（版本校验正常409）形成对照——乐观锁形同虚设。
|
||
|
||
**接口**：`POST /v1/im/meetings/{id}/cancel`
|
||
|
||
---
|
||
|
||
<a id="新增24"></a>
|
||
## 新增 24（P2）：群成员数存在两套互相独立、可永久失配的计数器
|
||
|
||
**证据强度**：✅ 实测确认（3个真实群交叉对照）+代码确认（2026-09-14重读源码确认未变）
|
||
|
||
**现象**：同一群同一时刻，`GET /groups/{topic}`与`/settings`显示的`member_count`，跟真实成员列表、qrcodes的`group_snapshot`可能不一致。
|
||
|
||
**根因**：业务层`im_group_settings.member_count`（只看`im_group_members`）与Tinode原生层`im_topics.subcnt`（只看`im_subscriptions`）是两套独立计数器，`mergeGroupSettingsPayload`（`server/im_http.go:8012`）无条件用业务层值覆盖了本来准确的subcnt值。
|
||
|
||
**接口**：`GET /v1/im/groups/{topic}`；`/settings`；`POST /groups/{topic}/qrcodes`；`GET /groups/{topic}/members`
|
||
|
||
---
|
||
|
||
<a id="新增25"></a>
|
||
## 新增 25（P2，产品需求缺口）：link类型消息——协议层面可构造，但没有任何真实用户可从webapp UI触达的路径
|
||
|
||
**证据强度**：✅ 实测确认（正反两方向均构造真实数据验证）
|
||
|
||
**现象**：WS`{pub}`可直接构造出`content:{url:...}`扁平结构被判定为link类型（可收藏可搜索），但`im_webapp`所有正常发送路径产出的content都不是这个形状，"我的收藏-链接"等tab对真实用户永远是空的。
|
||
|
||
**接口**：WS `{pub}`（消息发送），无特定REST路径
|
||
|
||
---
|
||
|
||
<a id="新增30"></a>
|
||
## 新增 30（P2）：青少年模式开启后不对任何功能做实际限制，`enforced` 恒为硬编码false
|
||
|
||
**证据强度**：✅ 实测确认（2026-09-14重新实测，未变）+代码确认
|
||
|
||
**现象**：restriction_items三项（深夜免打扰/内容过滤/支付守护）的`enforced`恒为硬编码false，全仓库穷举确认没有任何消息发送/好友添加/群聊/支付相关接口会查询用户的青少年模式状态。
|
||
|
||
**接口**：`GET /v1/im/settings/youth-mode`
|
||
|
||
**⚠️ 注**：`im_webapp`已明确移除青少年模式这个前端功能（用户产品决策，非技术限制），这条对当前`im_webapp`已无实际影响，仅为完整性保留在清单里。
|
||
|
||
---
|
||
|
||
<a id="新增31"></a>
|
||
## 新增 31（P2）：`POST /reports/abuse` 不校验 `requires_description`，可以对必填原因提交空描述
|
||
|
||
**证据强度**：✅ 实测确认+代码确认（2026-09-14重读源码确认未变）
|
||
|
||
**现象**：某原因码（如illegal/other）的`requires_description`为true，但提交该reason_code、description为空依然200成功——代码里只校验了`description`长度上限（500），从未检查对应`reason_code`是否要求必填。
|
||
|
||
**接口**：`POST /v1/im/reports/abuse`
|
||
|
||
---
|
||
|
||
<a id="新增32"></a>
|
||
## 新增 32（P2）：系统通知已读接口对已有 `read_at` 的通知，响应会原样回显客户端提交的值，但真实存储值不变
|
||
|
||
**证据强度**：✅ 实测确认+代码确认（2026-09-14重读源码确认未变）
|
||
|
||
**现象**：对已有read_at的通知重复调用已读接口，响应200并原样回显本次提交的read_at（哪怕故意传明显不同值），但真实存储的read_at纹丝不动。
|
||
|
||
**根因**：`TenantSystemNotificationMarkRead`执行`UPDATE...SET read_at=COALESCE(read_at,?)`，已非空时保留原值；`serveIMSystemNotificationRead`（`server/im_http.go:3576`）直接回显请求体局部变量`readAt`，从未回读真实值。
|
||
|
||
**接口**：`POST /v1/im/system-notifications/{id}/read`
|
||
|
||
---
|
||
|
||
<a id="新增34"></a>
|
||
## 新增 34（P2）：企业注册申请接口对同一个统一社会信用代码没有任何去重/防重复提交机制
|
||
|
||
**证据强度**：✅ 实测确认+代码确认（2026-09-14重读源码确认未变）
|
||
|
||
**现象**：同一信用代码用三个不同幂等键连续提交三次，全部独立成功建单，与需求文档"应防止重复提交"矛盾。代码上`serveIMTenantApplications`直接调用`CreateTenantApplication`，没有先查询该信用代码是否已有pending申请。
|
||
|
||
**接口**：`POST /v1/im/tenant-applications`
|
||
|
||
---
|
||
|
||
<a id="新增41"></a>
|
||
## 新增 41（P2）：群禁言接口没有任何角色层级保护——管理员可以禁言群主、任何角色都能自我禁言
|
||
|
||
**证据强度**：✅ 实测确认（代码逐行核对根因，2026-09-14重读源码确认未变）
|
||
|
||
**现象**：GET成员列表明确标注群主`eligible:false`/`ineligible_reason:"owner"`，但`POST /groups/{topic}/mutes`对群主本人自我禁言、以及管理员禁言群主均返回200成功——代码只检查了操作者本人是否是管理员，从未检查目标成员的角色。
|
||
|
||
**接口**：`POST /groups/{topic}/mutes`；对照`GET /groups/{topic}/members?mute_eligible=true`
|
||
|
||
---
|
||
|
||
<a id="新增47"></a>
|
||
## 新增 47（P2）：真实文件上传大小上限是32MB，不是仓库配置声明的100MB，且这个真实上限从未被前端用来做任何提前校验
|
||
|
||
**证据强度**：✅ 实测确认（2026-09-14重测`GET /bootstrap`，`max_file_size`依然是33554432即32MB，与之前记录一致）
|
||
|
||
**现象**：`GET /v1/im/bootstrap`声明的`data.limits.max_file_size`是33554432（32MB），但代码仓库`tinode.conf`/`meetingim.conf`里配置的是104857600（100MB）——声明值和真实生效值不一致，且这个字段从未被前端读取用于上传前的预校验。
|
||
|
||
**接口**：`POST /v0/file/u/`（Tinode原生大文件上传）；`GET /v1/im/bootstrap`（`data.limits.max_file_size`）
|
||
|
||
**⚠️ 说明**：此前记录曾提到仓库配置文件已经改成一致的104857600，但线上实测一直是32MB——这次复核确认线上依然是32MB，怀疑部署环境的实际配置和仓库里能看到的配置文件不是同一份，或者中间有额外的网关/环境变量覆盖，建议后端确认线上部署实际生效的配置来源。
|
||
|
||
---
|
||
|
||
<a id="新增49"></a>
|
||
## 新增 49（P2）：日报/月报创建接口对日期只校验格式不校验范围，年份0000、2099均可创建并成功提交
|
||
|
||
**证据强度**：✅ 实测确认+代码确认（2026-09-14重读源码确认未变）
|
||
|
||
**现象**：`report_date:"2099-12-31"`、`"0000-01-01"`均能创建、保存草稿、提交成功走完整流程。`parseIMDate`只用`time.ParseInLocation("2006-01-02",...)`校验格式，没有任何年份范围校验。
|
||
|
||
**接口**：`POST /v1/im/reports/daily`（report_date）、`POST /v1/im/reports/monthly`（month）及对应的`/submit`接口
|
||
|
||
---
|
||
|
||
<a id="新增51"></a>
|
||
## 新增 51（P2）：会议创建接口不校验 `attendee_user_ids` 对应的用户是否真实存在，可创建任意规模的"幽灵参会人"
|
||
|
||
**证据强度**：✅ 实测确认+代码确认（2026-09-14重读源码确认未变）
|
||
|
||
**现象**：用50个语法合法但真实不存在的user_id+1个真实好友，一次性创建52人会议成功。`parseIMUserIDList`只做格式校验（`types.ParseUserId`）和去重，从未查询数据库确认这些用户真实存在。
|
||
|
||
**接口**：`POST /v1/im/meetings`
|
||
|
||
---
|
||
|
||
<a id="新增54"></a>
|
||
## 新增 54（P2）：日报/月报SUBMIT接口不校验必填内容，可提交完全空白的报告，与响应自身声明的 `validation.*_required:true` 矛盾
|
||
|
||
**证据强度**：✅ 实测确认（现象）+代码确认（2026-09-14找到确切根因：`TenantDailyReportSubmit`的UPDATE语句只匹配`report_id`/`author_id`/`version`，完全不检查`work_summary`/`next_plan`等内容字段）
|
||
|
||
**现象**：`work_summary`/`next_plan`均为空字符串的月报草稿直接调用submit，返回200且`status:"submitted"`，同时响应体自己声明这两个字段`validation.*_required:true`。
|
||
|
||
**接口**：`POST /v1/im/reports/daily/{id}/submit`、`POST /v1/im/reports/monthly/{id}/submit`
|
||
|
||
---
|
||
|
||
<a id="新增56"></a>
|
||
## 新增 56（P2）：青少年模式启用接口 `policy_version` 不做版本校验，传任意正整数即被无条件接受并永久覆盖
|
||
|
||
**证据强度**：✅ 实测确认+代码确认（2026-09-14重读源码确认未变）
|
||
|
||
**现象**：代码只检查`body.PolicyVersion <= 0`（必须是正数），从未跟服务端已知的当前真实policy_version做比对，传任意大的正整数都会被接受并覆盖存储值。
|
||
|
||
**接口**：`POST /v1/im/settings/youth-mode/enable`
|
||
|
||
**⚠️ 注**：同新增30，`im_webapp`已移除此功能，仅为完整性保留记录。
|
||
|
||
---
|
||
|
||
<a id="新增76"></a>
|
||
## 新增 76（P2）：`GET /app/releases/latest` 的 `platform` 参数只接受 `ios`/`android`，web端完全不支持检查更新
|
||
|
||
**证据强度**：✅ 代码确认（2026-09-14重读当前HEAD确认未变）
|
||
|
||
**现象**：`GET /v1/im/app/releases/latest?platform=web`恒定`400 MALFORMED_REQUEST {"details":{"field":"platform"}}`。
|
||
|
||
**接口**：`GET /v1/im/app/releases/latest`
|
||
|
||
**前端现状**：`AboutPage.tsx`捕获这个错误后显示"暂不支持检查更新"，不会一直转圈或显示假的"已是最新版本"。
|
||
|
||
---
|
||
|
||
<a id="新增77"></a>
|
||
## 新增 77（P2）：群公告接口响应里没有已读人数字段，设计要求的"已读N/M"功能无法实现
|
||
|
||
**证据强度**：✅ 实测确认+代码确认（2026-09-14重读`groupAnnouncementPayload`/`groupAnnouncementPayloadWithPermissions`确认未变）
|
||
|
||
**现象**：`GET /groups/{topic}/announcements/latest`真实响应确认没有任何"已读数"/"已读人数"相关字段，设计稿明确要求的"已读18/28"这类展示前端拿不到数据来源。
|
||
|
||
**接口**：`GET /v1/im/groups/{topic}/announcements/latest`
|
||
|
||
**前端现状**：不展示已读人数（没有编造假数据）。
|
||
|
||
---
|
||
|
||
<a id="新增78"></a>
|
||
## 新增 78（P2）：消息搜索/收藏/通话记录里，涉及用户/话题id的字段有不一致的裁剪或哈希化处理
|
||
|
||
**证据强度**：✅ 实测确认（三处独立复现）
|
||
|
||
**现象**：
|
||
- `GET /topics/{topic}/messages/search`的`items[].from`、收藏`type:"text"`的`snapshot.from`：真实user_id被裁掉`usr`前缀（如`usrH5dvZ3ckWxo`变成`H5dvZ3ckWxo`），直接拿这个值和当前用户完整id比较会永远为false。
|
||
- 收藏的`source.topic`（P2P来源）、通话记录`GET /calls`的`topic`字段：用的是服务端内部`p2p...`哈希形式，不是SDK寻址用的`usr...`形式，客户端没有办法把这个哈希反解回对方user_id。
|
||
|
||
**接口**：`GET /v1/im/topics/{topic}/messages/search`；收藏接口的`snapshot.from`/`source.topic`；`GET /v1/im/calls`的`topic`
|
||
|
||
**前端现状**：都补了对应的兜底逻辑（`normalizeSender()`补回`usr`前缀；`p2p`前缀的topic降级显示"单聊消息"通用文案），不会崩溃，只是丢失了直接寻址能力。
|
||
|
||
---
|
||
|
||
<a id="新增82"></a>
|
||
## 新增 82（P2，2026-09-14新发现）：群设置缓存反序列化失败，高频出现，覆盖大量不同群
|
||
|
||
**证据强度**：✅ 实测确认（真实运行日志，25分钟窗口内3个pod合计242次，覆盖十几个不同真实群）
|
||
|
||
**现象**：`cache group settings[{topic}]: read failed: Uid.UnmarshalJSON: invalid length`，几乎是常态出现，不是个别数据问题——说明这条缓存读取逻辑本身有系统性bug，大概率是并发访问时缓存里的数据被写坏/读到了不完整的中间状态。其中至少一次复现（`grpDclMebv3MuI`）是被我们自己的并发请求触发的，其余多次是某个后台任务在循环访问一批固定的群时触发的。
|
||
|
||
**接口**：内部缓存逻辑，不直接对应某个REST接口，但会影响所有需要读取群设置的接口的正确性
|
||
|
||
---
|
||
|
||
<a id="新增83"></a>
|
||
## 新增 83（P2，2026-09-14新发现）：`media serve` 死锁没有捕获重试
|
||
|
||
**证据强度**：✅ 实测确认（真实运行日志，25分钟窗口内3个pod合计82次）
|
||
|
||
**现象**：`Error 1213 (40001): Deadlock found when trying to get lock; try restarting transaction`——MySQL自己在错误信息里就写明了"try restarting transaction"，这是标准的死锁处理方式，但代码里没有捕获这个特定错误码后自动重试，命中死锁的请求直接失败。
|
||
|
||
**接口**：`GET /v0/file/s/{id}`（文件服务）
|
||
|
||
---
|
||
|
||
<a id="新增84"></a>
|
||
## 新增 84（P2，2026-09-14新发现）：内部周期性后台任务"media gc"约每50秒触发一次MySQL驱动层连接损坏
|
||
|
||
**证据强度**：✅ 实测确认（真实运行日志，从09:42到10:03连续观察，间隔稳定在46-67秒之间，与是否有外部请求流量无关）
|
||
|
||
**现象**：`[mysql] connection.go:215 busy buffer`紧接着`packets.go:68 [warn] unexpected sequence nr: expected 0, got 5`，然后`media gc: N driver: bad connection`——这是MySQL驱动协议层面的连接状态错乱，是同一个进程内部对同一条MySQL连接被并发误用导致的典型症状，不是网络问题。
|
||
|
||
**与PXC迁移的关系**：这个问题的出现时间与本次复核发现的数据库迁移（旧VM单机MySQL → 新k3s集群PXC）时间点吻合，怀疑与迁移相关，但没有直接证据（比如没有看到这个后台任务代码里调用了新增的PXC兼容分支），仅供后端排查参考。
|
||
|
||
**接口**：内部后台任务，不直接对应外部接口，但可能影响同一时间段内其它数据库操作的稳定性
|
||
|
||
---
|
||
|
||
<a id="新增85"></a>
|
||
## 新增 85（P2，历史遗留，曾用编号"新增7"记录在`docs/IM-后端问题清单-2026-09-04.md`但未被带入本清单，本次复核重新收录）：按查询参数区分的缓存，写操作后特定参数组合的结果有明显滞后
|
||
|
||
**证据强度**：✅ 实测确认（提升管理员后90秒以上仍查不到）；⚠️2026-09-14本次复核未重新实测（判断优先级较低，仅确认历史记录未遗漏）
|
||
|
||
**现象**：`POST /groups/{topic}/admins/batch`提升成功（version从1到2），但`GET /groups/{topic}/members?role=admin`反复查询超过90秒仍然是`items:[]`——用直连接口的方式排除了前端自己的客户端缓存，是服务端按`role=admin`这个具体参数组合单独缓存了旧的空结果，写操作没有使它失效。
|
||
|
||
**接口**：`GET /v1/im/groups/{topic}/members?role=admin`（及其它类似的按查询参数缓存的接口）
|
||
|
||
---
|
||
|
||
<a id="新增86"></a>
|
||
## 新增 86（P2）：`GET /calls` 响应字段结构与协议文档完全不同
|
||
|
||
**证据强度**：✅ 实测确认（真实响应逐字段核对）
|
||
|
||
**现象**：协议文档描述的字段形状和真实响应完全对不上——没有`peer`对象，只有扁平的`peer_user_id`（真的是`usr...`形式）；没有`incoming`布尔值，而是`direction:"incoming"|"outgoing"`字符串；时间戳拆成了`created_at/started_at/finished_at/updated_at`四个字段，没有单一的`ts`；`topic`字段是`p2p...`哈希形式（同新增78的毛病）。
|
||
|
||
**接口**：`GET /v1/im/calls`
|
||
|
||
**前端现状**：已按实测字段改正类型声明和渲染逻辑。
|
||
|
||
---
|
||
|
||
<a id="新增87"></a>
|
||
## 新增 87（P2）：群二维码铸造/解析两个接口对同一份群数据用了不同的字段名，解析接口还多了一个文档没提到的字段
|
||
|
||
**证据强度**：✅ 实测确认（真实铸造+解析双向验证）
|
||
|
||
**现象**：`POST /groups/{topic}/qrcodes`（铸造）响应把群信息放在`group_snapshot`字段下；`POST /qrcodes/resolve`（解析，`purpose:"join_group"`）响应把同样性质的数据放在`group`字段下——同一份数据两个接口用了不同字段名。另外`resolve`响应还带了一个协议文档完全没提过的`status`字段，扫描"自己已经在的群"时返回`status:"joined"`；"真的还不是成员"这个场景下`status`具体是什么值没有实测到（当时没有第二个测试账号）。
|
||
|
||
**接口**：`POST /v1/im/groups/{topic}/qrcodes`；`POST /v1/im/qrcodes/resolve`
|
||
|
||
**前端现状**：做了双重兜底读取（同时尝试`group_snapshot`和`group`两个字段名）；`status`按"不是joined就走提交申请"的宽松逻辑兜底处理。
|
||
|
||
---
|
||
|
||
<a id="新增88"></a>
|
||
## 新增 88（P2，未定论，需要后续继续观察）：部分明显应该命中的关键词搜索返回空结果
|
||
|
||
**证据强度**：⚠️实测确认现象，但成因未定论
|
||
|
||
**现象**：在真实群里搜索"验证"/"链接"等明显应该命中历史消息的关键词，一度返回`items:[]`，同一时间搜索"测试"能正常命中。2026-09-14复测：搜索"验证"这次能正确命中真实消息了，看起来比之前有改善；但"链接"依然返回空——不过这次没能确认这个群里是否真的存在包含"链接"二字的消息，不能算作确凿的回归证据。
|
||
|
||
**接口**：`GET /v1/im/topics/{topic}/messages/search`
|
||
|
||
**建议**：这条目前证据不够充分下定论（可能是搜索索引/召回策略的问题，也可能是测试数据本身的问题），建议后续有更多测试数据时再复核一次。
|
||
|
||
---
|
||
|
||
<a id="新增89"></a>
|
||
## 新增 89（P1，2026-09-24）：文件审核任务无 Worker 消费，带图养成动态永久无法发布
|
||
|
||
**证据强度**：✅ 测试环境真实日志 + 数据库 + 代码确认
|
||
|
||
**现象**：用户发布带图动态后，动态保持 `status=reviewing,audit_status=pending`，`scope=friends`列表只查询 `published` 状态，因此列表返回空。实例动态 `1577072518975639552` 的两条图片审核任务（`aliyun_green` 和 `aliyun_sas`）均为 `pending`。
|
||
|
||
**根因**：文件上传时会无条件向 `im_file_review_tasks` 插入内容审核和恶意文件检测任务，但 IM 当前仅有阿里云提交/轮询客户端，没有实现读取、执行和回写这些任务的 Worker。测试库 `meeting_im.im_file_review_tasks` 共有 174 条任务，全部为 `pending`，`attempts=0`。
|
||
|
||
**当前临时策略**（2026-09-24 确认）：图片审核暂时关闭并默认通过。`cultivate_server` 仍调用 IM 校验文件存在性、归属和上传完成状态，但不再因文件审核的 `pending/risky` 状态阻塞动态发布。文字内容审核保持原有逻辑。
|
||
|
||
**待正式解决**：
|
||
|
||
1. 在 IM 中实现文件审核 Worker，完成任务抢占、阿里云提交/轮询、重试、超时、失败降级和结果回写。
|
||
2. 区分内容审核与恶意文件检测是否真正启用，未启用的检测不得创建永久 `pending` 的任务。
|
||
3. Worker 稳定上线后恢复 `cultivate_server` 的图片审核门禁，并确定现有 174 条历史任务的补偿或废弃策略。
|