我在 Zulip 找到两个 bug，结果维护者两周前就提交过了
来源：dev.to — 2026-08-09
📋 概述
作者为 DEV 的"夏日 Bug 粉碎"挑战赛在 Zulip 代码库中找到了两个真实的数据损坏 bug——Slack 导入器在迁移工作区时会静默打乱消息。但在动手修复前，他先搜索了 issue 追踪器，发现维护者早在两周前（6 月 30 日）就开了 #39650 号 issue，系统性地审计了 Slack 导入路径，而他发现的 bug 恰好都在清单上。于是作者两次转向：在最新的 Microsoft Teams 导入器中发现了一个尚未上报的同源 bug（latent twin），并认领了维护者 PR 未触及的一个未防护的时间戳排序键——它背后还隐藏着一个静默 NaN 失败模式。最终作者提交了两个 PR（#39813、#39814），每个都附带一个能在旧代码上失败的测试。
🔑 核心要点
- 作者选择 Zulip 作为狩猎场，因为它后端测试覆盖率极高、mypy 严格、lint 严格，lint 级 bug 存活不了，只能找逻辑级 bug
- 发现的两个 bug 都已被维护者在 issue #39650 中确认，作者"比自己的发现晚了整整两周"
- 第一次转向：在最新的 Microsoft Teams 导入器中找到了同一 bug 类别的、尚未上报的隐藏变体
- 第二次转向：认领维护者 PR 未触碰的未防护时间戳排序键，深挖后发现其背后还藏着一个静默 NaN 失败模式
- 两个 PR（#39813、#39814）都带着能在旧代码上失败的回归测试
- 核心教训：提交任何修复前先搜 issue 追踪器，避免重复劳动，并把精力转向真正无人认领的漏洞
💡 金句
我比自己发现的 bug 晚了整整两周——搜索 issue 追踪器，才是动手写第一行修复之前真正该做的事。
👍 0
👎 0
← 返回 dev.to 首页