im_webapp

Files

T

Your NameandClaude Sonnet 5 0824502ddd fix(web): 全新单聊(usr别名)会话消息收不到/在线状态错误——URL没跟上SDK重命名

真实两账号复现：好友刚加上、双方都还没发过消息的单聊，发消息表现为"发了
和没发一样"（无失败提示，但对方收不到），会话头部同时显示错误的裸ID和
"离线"（即使对方明明在线）。

根因（读tinode-sdk真实源码+原生协议脚本交叉验证，非猜测）：这类会话从
"对方user_id"（usr...）这个地址进入，服务端订阅成功后会返回一个不同的
真实内部话题名（p2p...哈希）。SDK的Topic#subscribe在topic对象处于
`_new`状态时（每个新建对象默认如此）会把本地缓存从usr...改名到这个真
实名字——但本组件的submit()/头部展示/MessageBubble的retry()全都各自
独立调用`tinode.getTopic(topicId)`，用的是URL里那个没变过的usr...字符
串。改名发生后再调用`getTopic('usr...')`是一次缓存未命中，会凭空造出
一个全新的、从未真正订阅过的"替身"对象——发送/已读/在线状态全部作用在
这个空对象上，而真正收到数据的是已经改名的那个对象，两者从此互不相干。

用一个独立的原生WS协议脚本验证了根因：直接订阅+发布到同一个usr别名，
服务端确认消息真的送达并持久化（用一次全新订阅的历史记录能拉到），证
明"消息发不出去"是假象，真正的问题在于客户端读的从来不是收到数据的那
个对象。

修复：openConversation()解析出的topic对象一旦.name和URL参数不一致
（即刚刚被服务端改名），立刻用real name替换当前URL（replace，不留历
史记录）。这样一来，本组件后续所有`getTopic(topicId)`都会读到同一个、
真正接了收数据的对象，而不是每次都对着URL里那个过期字符串重新变出一
个空壳。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-09-16 11:43:56 +08:00

AttachmentPreview.tsx

feat(web): complete groups/contacts/favorites/settings/calls/system domains + extensive review-round fixes

2026-09-09 20:16:33 +08:00

ChatListColumn.tsx

fix(web): 修复自聊天显示为原始topic id、主发送/重试路径未重新订阅话题

2026-09-16 10:44:19 +08:00

ConversationView.tsx

fix(web): 全新单聊(usr别名)会话消息收不到/在线状态错误——URL没跟上SDK重命名

2026-09-16 11:43:56 +08:00

DetailColumn.tsx

feat(web): 用符合系统风格的组件替换全部 window.alert/confirm