SIGKILL 之后任务停在 STARTED 状态 状态机缺了哪一步

后台任务列表里有 213 条记录状态停在 STARTED，开始时间是 6 小时前，进程已经不在了，前端一直在转圈。第一次遇到会往复杂处想，其实漏掉的多是个小前提。

UPDATE task_record SET status='FAILED', error='timeout',
  finished_at=NOW()
WHERE status='STARTED' AND started_at < NOW() - INTERVAL 2 HOUR;

task_track_started 打开后进入任务就写 STARTED，正常结束才写 SUCCESS。进程被 SIGKILL 时没有钩子能改状态，数据库里就留下这个中间态。这一点先确认清楚，后面就不用反复试。

「任务超时状态残留」这类改动最怕改一半，回滚脚本先准备好，再动生产。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。

改完隔一天再看一次，当场正常不代表能稳住。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。

具体做法是，给状态加超时判定 超过 task_time_limit 的 STARTED 视为失败；用 beat 起巡检任务 每 5 分钟扫一次超时记录；修正状态时写入 error 字段 标明被超时回收；前端对超过阈值的记录不再显示 loading。

改完照着核一遍，巡检跑一轮后 列表里没有超过 2 小时仍是 STARTED 的记录 前端 loading 状态消失。