cbfee6b15655e698a46dfbb7a0ab0595771f1c13
接 99c8bc3 多代理深度 code review,治本两个 blocker:
I1 软删除 × 唯一约束 → 静默丢消息(撤批次2):
- MessageRetryQueueDO 走 @TableLogic 逻辑删除,deleteByMessageIds 实为
UPDATE deleted=1,物理行残留;批次2 的 uk_pmrq_message_id 只盖 message_id,
与残留行冲突 → 同一 message_id 再入队抛 DuplicateKeyException → catch 再
selectOne 仍 null(软删行不可见)→ concurrent==null 静默 return → 消息永久丢失。
- 撤回:删迁移 SQL、移除 DuplicateKeyException catch 与 import,回到纯
selectOne→insert/update;applyRetryUpdate(含批次1 限流逻辑)保留为单点调用。
I2 SENDING 行泄漏 + 周期空转(最小治本):
- processSingleRetry 的 else 把"保留中间态"白名单误用在重认领路径;能被重认领
说明 120s 租约已过期、20s 回执窗口早过,SENDING/PENDING 属卡住却被保留 →
永不删除/推进、到不了 12h 兜底、周期空转。改前的无条件 delete 会自愈。
- 改回 else { delete }(重认领即清理);删死代码 isTerminalState / INTERMEDIATE_STATES;
保留 finalizeRetryLease 的 SENDING→return(发完即时窗口保住行,批次1 修 R1 关键)。
测试:RetryDecisionLogicTest 删 isTerminalState 两例、清死 import,余 4 例全绿;
全模块重编译通过。设计见 docs/superpowers/specs/2026-06-19-sms-retry-blockers-fix-design.md。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Description
Languages
Java
100%