Sidekiq Web界面中/busy页面报错问题分析与解决

问题背景

在使用Sidekiq 7.3.4版本时，开发人员发现Web界面中的/busy页面无法正常加载，而其他页面如队列、重试等都能正常工作。错误信息显示为"no block given (yield)"，这是一个Ruby中的LocalJumpError异常。

错误分析

通过错误堆栈可以清晰地看到问题发生在Sidekiq的API模块中，具体是在lib/sidekiq/api.rb文件的932行。这个错误通常发生在尝试调用yield但当前方法没有接收到块参数时。

深入分析堆栈信息，我们可以发现错误实际上是由descriptive_statistics gem(版本2.5.1)引发的。这个gem试图对Sidekiq进程数据进行统计计算时出现了问题。

根本原因

问题并非由Sidekiq本身引起，而是由于项目中引入了descriptive_statistics这个第三方统计库。这个库在与Sidekiq的进程统计API交互时，没有正确处理枚举器的情况，导致了块参数缺失的错误。

具体来说，当/busy页面尝试计算以下统计信息时触发了错误：

• 进程数量(processes.size)
• 总并发数(processes.total_concurrency)
• 总RSS内存使用量(processes.total_rss)

解决方案

解决这个问题非常简单：

1. 从Gemfile中移除descriptive_statistics gem
2. 运行bundle install更新依赖
3. 重启Sidekiq服务

移除这个非必要的统计库后，/busy页面就能正常加载和显示所有信息了。

经验总结

这个案例给我们几个重要的启示：

1. 依赖管理要谨慎：不是所有看起来有用的gem都能与其他库完美配合，特别是当它们尝试对复杂对象进行统计分析时。

2. 错误分析要全面：表面上看是Sidekiq报错，但实际根源在另一个gem。查看完整堆栈跟踪对于定位问题至关重要。

3. 最小化依赖：只保留真正必要的依赖可以减少这类兼容性问题。在这个案例中，Sidekiq自身的统计功能已经足够，不需要额外的统计库。

4. 版本兼容性：即使像descriptive_statistics这样成熟的库，也可能与特定版本的Ruby或其他gem存在兼容性问题。

通过这个问题的解决，我们不仅修复了/busy页面的显示问题，也优化了项目的依赖结构，使其更加稳定可靠。