在 Zulip 源码里找 Bug 结果发现维护者两周前就报过了

在 Zulip 这种代码质量极高的项目里找 Bug 简直是场噩梦，因为它的后端测试覆盖率高得离谱，而且用 mypy 和 ruff 刷得干干净净，想靠搜 Lint 级别的低级错误基本没戏。所以我直接切入了最容易出问题的逻辑地带：数据导入模块。这种处理第三方导出文件的模块天然就是个“雷区”，因为输入数据质量极其不稳定，而且迁移通常是一次性的，一旦某个边缘 case 没处理好，整个工作区就废了。

我当时信心满满地在 Slack 导入逻辑里揪出了两个会导致数据损坏的实战 Bug：一个会导致消息在迁移时被静默打乱，另一个则会让消息丢失。结果当我准备写修复代码前去搜 Issue 列表时，发现维护者在 #39650 里早就把这俩坑给标出来了，而且描述得比我还要精准。

虽然被“抢先”了，但这次踩坑经历反而让我找到了真正的突破口。我发现虽然 Slack 的导入逻辑被审计过了，但类似的逻辑缺陷在 Microsoft Teams 导入器里依然存在。我通过对比代码，迅速定位到了一个未被报告的隐藏 Bug，并顺带解决了维护者 PR 中遗漏的一个时间戳排序 key 缺失问题（这个坑会导致一个静默的 NaN 失败模式）。

这次折腾下来，我提交了两个 PR，每个都配了能让旧代码跑挂的测试用例。最让我感触的是，在处理那个时间戳 Bug 时，我还跟 AI 吵了一架，它一直试图给我一个简化方案，但实际情况是必须保证微秒级的精度才能避免不同线程合并。

这次实操给我的最大教训就是：在成熟的开源项目里，不要试图在已知路径上证明自己，得去那些“逻辑镜像”的地方找机会。

具体到代码层面的坑点，比如这个线程 ID 计算的逻辑：

# 错误示范：只截取到秒，导致一秒内多条消息会被合并
thread_key = f"{message_ts.strftime('%Y/%m/%d %H:%M:%S')} {parent_id}"

正确的做法必须包含微秒或者直接使用原始时间戳字符串，否则只要有 Bot 在一秒内发了两条消息，后续的回复全都会乱套。