AD-019：分析任务中断恢复——启动标记 FAILED（SPI-5 评估结论）

• 日期：2026-08-13
• 背景：AD-018 约定 SPI-5（Redis 任务队列）「留待有真实并发压测数据后评估」。本轮完成压测基线：
• 正常运行：4 项目并发触发 FULL 分析，全部 SUCCEEDED（当前内存 @Async 线程池 core 2 / max 3 / queue 50 满足常规并发，3 秒内完成）。
• 崩溃/重启：backend 执行前或执行中崩溃 → 残留 PENDING/RUNNING 任务无声丢失——重启后无恢复机制，任务永远停在 PENDING/QUEUED（实测模拟残留 8 秒+ 无任何推进），用户无感知、无重试、无失败标记。
• 决策：
• 选「启动恢复标记」，不选 Redis 队列：核心痛点是「无声丢失」（任务卡死且用户不知情），低成本方案 = backend 启动时扫描 PENDING/RUNNING 残留 → 标记 FAILED（用户可见、可重新触发）；Redis 队列需重写任务调度（生产者/消费者/幂等/与 DB 状态机协调），风险高，且当前产品无「任务必须自动重跑」的硬需求（重跑由用户触发即可）。
• 实现：新增 StartupTaskRecovery（ApplicationRunner）——启动时把 PENDING/RUNNING 分析标记 FAILED（error_message="服务重启导致任务中断，请重新发起分析"），并把受影响项目的 ANALYZING 状态恢复为 READY。
• 边界：恢复仅标记失败、不自动重跑（用户重新触发分析）；单实例部署假设（启动时存在的 PENDING/RUNNING 必为上次进程残留）。
• 影响：backend 新增 1 个组件；分析状态机/线程池不动。
• 验证：模拟残留 PENDING 任务 → 重启 backend → 任务自动标记 FAILED、项目状态恢复 READY。
• 后续：若出现「任务必须自动重跑不丢」的硬需求（如任务队列化 + 多实例），再评估 Redis 队列（届时更新本 AD）。