fix: 查重 worker 无限重试 bug + 补 3 个 API/repository 单测 (#1661 follow-up) #1680
Reference in New Issue
Block a user
Delete Branch "fix/duplication-ci-coverage-retry"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
修复内容
1. 修复无限重试 Bug(duplication_check.py)
问题:
except Exception块中raise self.retry(exc=e, countdown=60)无条件执行,即使已达 max_retries 上限仍会 retry,导致 Celery 任务无法正确标记 failed。修复:
self.request.retries >= self.max_retries时:标记 failed + 返回{"ok": False, ...},不再 retryself.request.retries < self.max_retries时:才raise self.retry(countdown=60)2. 补 3 个单测提升 diff coverage
新增
tests/unit/test_duplication_api_enqueue.py:test_upload_enqueue_calls_celery_tasktest_retry_enqueue_calls_celery_tasktest_repository_update_calls_session_commit验证
🚀 预览环境已部署
【阻塞级判定】
📊 审查概览
🔴 阻塞级问题(必须修复)
if "repo" in locals() and self.request.retries >= self.max_retries:将“仓库对象是否存在”与“是否达到重试上限”耦合。如果repo初始化失败(例如数据库连接断开),repo不会存在于locals()中。此时即使self.request.retries >= self.max_retries为真(已达重试上限),整个if块也会被跳过,直接执行后续的raise self.retry(...)。这将导致任务忽略max_retries限制,陷入无限重试或直至 Celery 全局上限,造成资源浪费和日志堆积。repo是否存在,只要达到重试上限,都应停止重试。建议修改逻辑如下:💡 改进建议(不阻塞合并)
{"ok": False, ...}。在 Celery 中,显式返回值会使任务状态被标记为SUCCESS。如果下游系统或监控依赖 Celery 的任务状态(如on_failure回调、Flower 监控面板)来判断任务失败,这些任务将被误判为成功。建议确认业务逻辑是否依赖返回值内容判断成败,如果是,则当前代码可行;如果不是,建议抛出异常(如raise MaxRetriesExceededError("...") from e)以使 Celery 正确记录FAILURE状态。✅ 良好实践
repository.update调用session.commit的单元测试,确保了数据持久化的可靠性。exc_info=True,便于排查堆栈信息。🤖 由 AI 代码审查机器人自动生成 | 2026-09-04 03:30:58 | 模型:
🗑️ 预览环境已清理
PR #1680 已关闭或合并,对应的预览环境已被清理。