13-06 扩展导出恢复

题目

让服务重启后能列出 queued 任务，设计一次重新执行动作，比较恢复前后的状态，并检查其他用户无法领取它。

推导与做法

重启后 queued 是数据库中的持久状态，不能只保存在进程内列表。列表接口先按当前 owner 取任务；重试时用“id 相同且 status=queued”的条件领取，竞争请求无法同时领取成功。

领取提交后，后台逻辑使用新的 Session 生成结果并保存 done。演示先建立 queued 记录，Bob 领取得到 403，Alice 重试后变成 done。实际进程若可能在 running 时退出，还需记录租期并把过期任务重新归队。

过程图

%% 每个节点保留输入、执行位置或执行后的实际状态。 flowchart TD S0["重启后从数据库查queued"] S1["先核对任务owner"] S0 --> S1 S2["条件UPDATE queued→running领取"] S1 --> S2 S3["新Session生成结果并提交done"] S2 --> S3 classDef default fill:#EEF0FB,stroke:#4657B5,color:#24324A linkStyle default stroke:#4657B5

实现与运行

查看带注释实现。本题与相关处理函数放在同一章节代码文件中；启动工具负责定位相邻项目和选择题号。

在配套目录的 FastAPI/api_project 中运行。先按项目 README 执行 uv sync --locked。

# 使用项目解释器运行本题，题号决定执行哪一组演示。
uv run python "../../学习索引/参考实现/代码/ch13.py" 13-06

程序按题号输出处理后的值、查询结果或状态。先和前面的手算比较，再修改一项输入重跑。

查看本题运行结果

# 与上面的手算状态和题目数值逐项比较。
{
  "queued": [
    {
      "id": "recover-job",
      "status": "queued"
    }
  ],
  "other_owner": 403,
  "recovered": {
    "id": "recover-job",
    "status": "done"
  }
}