Jackett项目中的BrokenStones索引器递归登录问题分析与修复

问题背景

在Jackett v0.22.704版本中，用户报告了一个关于BrokenStones索引器的严重问题。当用户配置了Cookie（特别是启用了2FA认证的情况下）并进行测试或搜索操作时，系统会进入无限递归循环，最终导致内存耗尽(OOM)错误。

技术分析

问题现象

1. 递归错误：系统不断重复抛出"Your cookie did not work"错误，形成深度嵌套的异常堆栈
2. 资源耗尽：持续递归导致内存使用量激增，最终触发OOM Killer终止进程
3. 线程池饥饿：监控日志显示心跳检测超时，表明系统资源被大量占用

根本原因

问题出在GazelleTracker基类的错误处理逻辑上。当Cookie验证失败时，系统没有正确终止验证流程，而是进入了以下递归循环：

1. 尝试使用配置的Cookie访问BrokenStones
2. 验证失败后触发重新登录流程
3. 新的登录尝试再次失败，重复步骤1-2

这种设计缺陷导致每次验证失败都会在异常处理中嵌套一个新的验证尝试，形成无限递归。

解决方案

开发团队通过提交59f29ab修复了这个问题，主要修改包括：

1. 移除递归逻辑：重构了Cookie验证流程，避免在错误处理中再次触发验证
2. 优化错误处理：当Cookie无效时直接返回明确的错误信息，而不是尝试重新验证
3. 资源保护机制：增加了对递归深度的限制，防止类似问题再次发生

技术启示

1. 递归的危险性：在错误处理中使用递归需要特别谨慎，必须设置明确的终止条件
2. 资源管理：网络请求相关的功能应该考虑资源使用上限，防止DoS攻击或配置错误导致的系统崩溃
3. 防御性编程：对于用户提供的配置（如Cookie），应该进行有效性检查后再使用

最佳实践建议

对于使用Jackett连接需要认证的索引器的用户：

1. 确保Cookie信息完整且最新
2. 定期检查索引器配置是否仍然有效
3. 监控系统资源使用情况，特别是内存消耗
4. 及时更新到最新版本的Jackett以获取修复和改进

这个问题提醒我们，即使是看似简单的认证流程，也需要完善的错误处理和资源管理机制，才能确保系统的稳定性和可靠性。