Cursor 分析 bug 记录

工作忙起来的好处就是没时间思考，不停的在赶着一个又一个功能的迭代。但是昨天偶然听到一位父亲在给孩子讲述「西西弗斯」的故事，突然意识到就这样日复一日的一成不变下去，自己是不是就跟永不停歇一直推石头到山顶的西西弗斯一样。

注：这周紧张而繁忙的工作，让我在思考。AI 工具的发展在助力劳动者的同时是不是也给资本家提供了压榨劳动者的手段。

在前前后后接近 20 轮的压测过程中，不仅需要快速的相应压测出现的各种问题，还需要同时快速修复代码的 bug。

注：为 cursor gpt-5-fast 模型的分析能力点赞！

问题：QA 反馈压测环境的任务非预期退出？

分析：

针对报错的任务做初步的分析，粗估一下退出的原因
将非预期退出日志 + 模块丢给 cursor
cursor 分析过程简单总结：何你的这条日志被判定为 fatal ？
- 事件里 last_error_code 是 "7"，按错误码集合本不致命。
- 但 last_error_message 里包含 "Error code: 1013 ... SessionId: ...1007"。由于正则是 error\s+code.*1007，它会从 "Error code" 开始一直向后匹配，直到命中 SessionId 末尾的 "1007"，从而误判为致命错误。
也就是说，是"过宽"的正则把 SessionId 里的 "1007" 当成了错误码 1007。
cursor 修复方案简单总结：
- 将模式改为只匹配错误码字段本身，例如：r"error\scode:\s1007\b"；
- 更稳妥地优先使用结构化的 last_error_code 判断，再辅以消息匹配作为兜底，避免被 SessionId 等字段干扰。

总结：遇到不是自己写的模块出现 bug ，先不要慌，因为必要时刻可以请 cursor 出手。

问题: QA 反馈 uploader 服务出现问题

分析：

结论：边压测边分析自己的 bug ，似乎压力也没有那么大了不是。

问题： QA 反馈服务没有按照预期退出

分析：

根因又又又是因为数据竞争
但是这个非 cursor 修复的，原因是 cursor 没有办法本地复现，导致它在 fix 这个问题的时候花费了比较长的时间。
注: cusor 没办法本地复现的原因是有人定义的 interface 里，用了不支持导出的方法......

因为 Go 语言的一个特殊设计：如果接口中包含未导出的方法（小写字母开头），那么这个接口只能在定义该接口的包内实现。这是一个安全特性，确保未导出的方法只能在定义它们的包内部实现。

在我们的例子中：
1. internal 接口是在 xxx/yyy 包中定义的
2. 这个接口包含了一个未导出的方法 internal
人肉修复的方案总结：
- 首先，分析数据竞争产生的 Write/Read 的具体位置
- 然后，移除Write/Read 中的一个，防止数据竞争的产生
- 最后，果然每个人写代码都有每个人写代码的风格......

总结：遇到数据竞争的 case 不要慌，虽然是别人写出来的，但是咱也有处理的经验不是了。

注：以上的数据竞争展示隐去了部分内容

忙碌的连晚饭时间都要牺牲出来测试的一周终于结束了，开始搓搓手期待这个周末啦。