一个后台任务的排队、执行、取消与中断恢复

本文属于 Memory Center：AI 编程上下文与记忆系统工程实践，第 27 篇，位于“可靠后台任务”模块。案例背景统一采用实际开发项目；复现步骤使用脱敏教学样例，不代表特定生产事故。

从实际问题出发

“取消”按钮如果只修改页面状态，后台进程可能仍在运行并最终发布结果。可靠取消必须同时处理记录、进程和发布资格，重启恢复也要区分等待中的任务与中断的任务。

状态与执行事实一起判断

queued 尚未开始计算，running 已获得执行资源；取消排队与取消运行中的任务需要不同处理。进程退出前，清理代码不能假定资源已经不再使用。

图中展示的是本篇关注的职责和顺序。正常流程之外，还要结合下面的源码与实验检查失败分支；它不是对某次线上调用的运行时追踪。

重试不应抹掉历史

服务重启后，旧 running 不能被当成仍有活跃执行者；任务应明确标记中断，排队任务则按合同继续。失败、取消和中断具有不同原因，保留诊断才能决定是否重试。

关键源码与阅读方法

源码基线为 Memory Center 6e90553（文档标注 5.0.0b24）。定位：memory_center/platform/jobs.py，函数 cancel，起始行 511。

以下为当前基线中的函数代码；依赖项目模块，不能作为独立脚本执行。

    def cancel(self, job_id):
        job = self.store.get('job', job_id)
        if job['status'] in {'queued', 'running'}:
            return self.store.update('job', job_id, {'status': 'cancelled', 'finished_at': now()})
        return job

阅读时先找输入由谁提供，再区分纯计算、读取和写入；遇到异常或提前返回，追问调用方会得到什么，以及已有状态是否仍然有效。上面的代码只证明展示范围内的实现，跨模块行为应继续查看调用处和相应测试。

用一个小实验核对设计

建议在独立临时目录和隔离数据中操作，使用虚构的接口、文档与项目名称。

1. 分别取消排队与运行中的索引。
2. 等待进程退出。
3. 在隔离环境停止并重启服务后查看遗留任务。

**要核对的结果：**被取消任务不能发布，进程未退出时不能把它占用的目录当成安全垃圾。

可把观察记录为下表；没有执行的项写“未执行”，不能用设计预期冒充实测结果。

核对项	应保留的证据
使用条件	源码版本、配置、输入与项目范围
正常行为	实际返回、来源位置或状态变化
关键失败分支	错误码、可见结果与原状态是否保留
结论范围	已覆盖、未覆盖和需要进一步验证的条件

适用边界与继续阅读

本篇以静态源码与项目设计为依据，给出可执行的核对方法，未据此宣称已经完成新的性能或生产环境测试。不同版本的入口、默认值和底层实现可能变化，应先核对当前合同，再把方法用于自己的实际开发项目。

理解这一节后，可以回到专题总导航，沿同一模块继续阅读；顺序学习时使用专栏内的上一篇和下一篇。涉及具体技术选择，应连同本篇的代价与限制一起采用。