订单状态卡死的偶发 Bug 定位
给出一份订单状态偶发卡在「待发货」的现象描述与关键代码,让模型先质疑前提再定位根因,而不是直接改表象。
适用场景
- 线上偶发问题复现不了、团队已改过三版都没根治
- 想让模型先推翻自己的假设再动手改代码
- 接手别人写的状态机代码,需要快速摸清哪里会卡住
PROMPT
线上每天有十几单支付成功后卡在待发货,超过 24 小时不动,排查两周没结论。手上有状态机代码与近两周的订单号,本周要交给主管一份定位方案。 【计划】 1. 第一步列假设:至少三条没验过的假设,标准是每条都能被一条 SQL 证伪。 2. 第二步查流转:找出停在待发货且不再被捞起的路径,标准是画出状态图。 3. 第三步查并发:确认版本号会不会被旧消息覆盖,标准是给出可复现的时序。 4. 第四步给修法与副作用:最小改动堵缺口,标准是不引入新的死状态。 【执行】 1. 假设一:消息没投递,验证方式是查这十几单在消息队列里的投递记录。 2. 假设二:消费者收到但事务回滚,验证方式是按订单号查消费日志与连接报错。 3. 假设三:状态更新成功但定时任务没捞到,验证方式是比对更新时刻与扫描区间。 4. 流转与并发:重投三次后进死信无人处理;旧消息可能带老版本号回写覆盖新状态。 【回改计划】 1. 偏离点落在第四步:只加重试次数会把死信问题往后推,原计划需改。 2. 更新后计划:改为死信进补偿队列并由定时任务扫尾,重试次数维持三次。 3. 兜底设计:加一条超过 30 分钟未发货就主动查支付状态的补偿规则。 4. 最小改动:消费者失败落死信表,新增每分钟扫描任务,其余状态机不动。
复制后直接粘贴到模型使用