接口用 AsyncResult(task_id).state 查进度，任务日志里已经打印完成，接口返回的一直是 PENDING，刷新 10 分钟也不变。日志里能对上时间点，这种反而好排。
worker 配置的 result backend 是 db 3，Web 进程读的是 db 0，两个库里的 key 不在同一个地方。任务完成时确实写了结果，只是写到了另一个库。这一点先确认清楚，后面就不用反复试。
redis-cli -n 3 GET celery-task-meta-2f1c9a redis-cli -n 0 KEYS 'celery-task-meta-*' | head celery -A app inspect conf | grep -i backend
「任务结果查询失败」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
处理上按这个顺序：把 worker 和 Web 的 broker_url result_backend 抽到同一份配置；确认两边连同一实例和同一个 db 编号；用 redis-cli 直接看 celery-task-meta-<task_id> 是否存在；存在但读不到时检查 key 前缀和序列化格式。
结果对不对很好判断，同一个 task_id 在接口里 3 秒内从 PENDING 变成 SUCCESS redis 对应 db 里能看到 meta key。