feat: 任务失败后继续执行下一条 (#170)

2026-08-11 18:21:25 +08:00
parent b2c99840b3
commit 8b8a542cc5
14 changed files with 280 additions and 103 deletions
@@ -450,26 +450,25 @@ CREATE TABLE app_settings (
 |---|---|---|---|
 | （无记录） | `claimed` | `claim` 成功，任务首次写入本地库 | 任务协调器 |
 | `claimed` 已领取 | `running` | 工作线程开始操作设备 | 任务执行器 |
-| `claimed` | `retry_wait` | 设备连不上等可恢复错误，**还没碰过设备** | 任务执行器 |
 | `claimed` | `failed` | 任务数据不合法（缺必填字段、数量为 0 等） | 任务执行器 |
 | `claimed` | `cancelled` | 用户停止，且尚未开始执行 | 任务协调器 |
 | `running` 执行中 | `result_pending` | PDD 操作完成，**且结果已落库**（见 §5.1） | 任务执行器 |
-| `running` | `retry_wait` | 可恢复失败（页面超时、网络抖动），**且未进入不可逆阶段** | 任务执行器 |
-| `running` | `manual_review` | 需要人判断：多个订单候选、验证码、登录失效、价格超限、规格不确定 | 任务执行器 |
-| `running` | `failed` | 不可恢复且不需要人处理（商品下架、链接失效） | 任务执行器 |
+| `running` | `manual_review` | 登录、验证码、风控或不可逆采购等必须停队列并由人处理 | 任务执行器 |
+| `running` | `failed` | 本次采集或采购失败；失败上报成功后继续下一条，不自动重试当前任务 | 任务执行器 |
 | `running` | `cancelled` | 用户停止，且已到安全点、未进入不可逆阶段 | 任务协调器 |
 | `result_pending` 结果待提交 | `succeeded` | Admin 返回 `accepted: true` | 结果提交服务 |
 | `result_pending` | `manual_review` | 重试次数超上限仍提交不上去 | 结果提交服务 |
 | `manual_review / reconcile_purchase` | `result_pending` | 严格核对到唯一未付款订单，结果和 Outbox 已在同一事务落库 | 只读核单服务 |
-| `retry_wait` 重试等待 | `running` | 重新启动获取任务，或用户确认“重新执行”；**本地直接重跑**并新建 `task_runs` 记录 | 任务协调器 / 人 |
-| `retry_wait` | `failed` | 超过最大重试次数，且从未进入不可逆阶段 | 任务协调器 |
-| `retry_wait` | `manual_review` | 超过最大重试次数，但**曾经进入过不可逆阶段** | 任务协调器 |
+| `retry_wait` 旧数据/中断恢复 | `claimed` | 用户明确确认重新采集；自动获取不会选择该状态 | 人 |
 | `manual_review` / `succeeded` / `failed` / `cancelled` | `claimed` | 用户在 Client 明确确认重新采集；仅限采集任务，且没有未发送 Outbox | 人 |

-**注意 `retry_wait` → `running` 是纯本地操作。** 任务已经在本地库里了，重试直接重跑就行，
-**不需要再向 Admin 要一次**。没有租约，也就没有"重新获取执行权"这回事。
-当前 `retry_wait` 不包含倒计时。自动获取因可恢复采集错误停止后，界面必须显示
-“重试已暂停”；用户可以选择任务点击“重新执行”，或重新启动获取任务。
+自动流程对一条任务只执行一次。任务自身失败时写入 `failed`，界面按类型显示
+“采集失败”或“采购失败”；失败原因保存在 `last_error_code` 和
+`last_error_message`。只有用户明确点击重新采集或重新采购，才创建新的
+`task_runs` 记录再次执行。
+
+`retry_wait` 不再表示程序正在等待。它只兼容旧数据和“采集运行中异常退出”的恢复
+结果，界面同样显示为“采集失败”，并且不会被自动任务查询选中。

 ### 7.2 补充规则

@@ -478,7 +477,7 @@ CREATE TABLE app_settings (
 - `[必须]` 只有 Admin 返回 `accepted: true` 才能进入 `succeeded`，本地不许自己判定成功。
 - `[必须]` `manual_review` 不自动重新执行；只有用户在 Client 明确确认重新采集，才允许先回到 `claimed`。
 - `[必须]` 已经是 `succeeded`、`failed`、`cancelled` 的任务，不得被迟到的后台回调改回运行中状态；人工确认的重新采集除外。
- `[必须]` 每次重试都要新建一条 `task_runs` 记录（`attempt_no` 加 1），不许覆盖上一次的记录。
+- `[必须]` 每次用户手动重新执行都要新建一条 `task_runs` 记录（`attempt_no` 加 1），不许覆盖上一次的记录。
 - `[必须]` 采购任务不能从“重新执行”入口启动；重新采集不处理任何采购动作。

 ### 7.3 崩溃重启后怎么恢复
@@ -496,8 +495,9 @@ CREATE TABLE app_settings (

 一句话记住：**`irreversible_action_at` 有值 = 只准查，不准买。**

-可重试的设备错误在采购演练中也先进入 `manual_review`，不会因为技术上
-“可重试”就隐式重跑采购。这与采集任务的 `retry_wait` 规则不同。
+采集和采购都不自动重试。设备断开、登录、验证码、风控、Admin 不可用以及
+不可逆采购待核单属于全局阻塞，必须停止队列；普通任务自身失败并成功上报后继续
+下一条。

 ## 8. `pdd_data` JSON