为何discard_on未触发却执行retry_on？优先级或继承问题排查

问题根源 #

你遇到的问题核心是错误使用了Sidekiq的retry_on API，而非规则优先级或单纯的继承关系问题。

具体分析 #

Sidekiq的retry_on方法标准语法是：

retry_on(错误类或错误类数组, 配置选项哈希 = {})

你写的retry_on(BankError::NoResponseData, StandardError)属于用法错误——第二个参数应该是配置选项（比如重试次数attempts、等待时长wait），而非另一个错误类。当你把StandardError作为第二个参数传入时，Sidekiq会错误地将其解析为异常匹配范围，导致这个retry_on规则实际会捕获所有继承自StandardError的异常（包括你的ConnectionErrors::Error），毕竟StandardError是Ruby所有业务异常的父类。

虽然你先定义了discard_on(ConnectionErrors::Error)，但由于retry_on错误地覆盖了更宽泛的异常范围，当ConnectionErrors::Error抛出时，会被这个宽泛的retry_on规则优先匹配到，所以才会进入重试逻辑而非丢弃逻辑。

修复方案 #

1. 仅针对BankError::NoResponseData重试：修正retry_on的写法，将第二个参数改为配置选项哈希：

retry_on(BankError::NoResponseData, attempts: 3) # 可根据需求添加wait等其他选项

2. 针对多个特定错误重试：如果需要同时处理BankError::NoResponseData和其他特定异常，用数组传入多个错误类：

retry_on([BankError::NoResponseData, SomeOtherSpecificError])

补充说明 #

Sidekiq的错误处理规则是按定义顺序匹配，优先匹配更具体的异常类，但前提是规则定义正确。如果某个规则错误地匹配了父类异常，会覆盖所有子类异常的处理逻辑——这正是你当前问题的核心。

内容的提问来源于stack exchange，提问作者Dedy Puji