feat(selection): 补充策略执行结果查询链路

2026-08-09 09:34:46 +08:00
parent e9d06df5de
commit 9c1a1eac23
31 changed files with 3566 additions and 14 deletions
@@ -81,3 +81,90 @@ first = next(category for category in categories if masks[category].iloc[-1])
 target_index = frame.index[frame["trade_date"] == target_trade_date][0]
 matched = tuple(category for category in signal_order if masks[category].iloc[target_index])
 ```
+
+## Scenario: 持久化策略执行结果与 HTTP 重跑
+
+### 1. Scope / Trigger
+
+- Trigger：为已有历史选股公式增加每日批次持久化、HTTP 触发/查询和 Web 轮询时，沿用
+  `selection` bounded context；不要让查询请求重新计算公式。
+- 触发入口是 `POST /api/v1/selection/runs`，结果读取入口是
+  `GET /api/v1/selection/runs/{run_id}` 和
+  `GET /api/v1/selection/results?strategy=...&target_trade_date=...`。
+
+### 2. Signatures
+
+- `SelectionUniverseReader.load_execution_source(strategy: str, target_trade_date: date) -> SelectionExecutionSource`
+- `SelectionRunStore.prepare_run(strategy, target_trade_date, source, *, rerun: bool) -> SelectionRun`
+- `POST /api/v1/selection/runs` 请求：
+  `{"strategy": "zhixing_b1", "target_trade_date": "YYYY-MM-DD", "rerun": false}`；成功返回
+  `202` 和 `{run_id, strategy, target_trade_date, status: "running"}`。
+- `selection_run` 的业务唯一键是 `(strategy, target_trade_date)`；
+  `selection_run_item` 的唯一键是 `(run_id, ts_code)`；
+  `selection_signal` 的唯一键是 `(run_id, ts_code, category)`。
+
+### 3. Contracts
+
+- `load_execution_source` 必须先确认目标日存在 `strategy_eligible=true` 且已完成的
+  `success`/`partial_success` 市场同步批次，并且股票为 active 且目标日 qfq bar/basic
+  完整；来源批次 ID、目标数、实际参与数和 coverage 写入 run。
+- 市场数据预检在删除旧结果之前执行。预检失败不得创建新 run，也不得破坏已有终态结果。
+- 同一策略同一目标日的重跑在一个短事务内使用 advisory transaction lock，删除旧 run
+  （依赖子表 `ON DELETE CASCADE`）并创建唯一的新 `running` run；长时间的逐股计算在
+  事务外执行。
+- 查询响应必须返回 run 状态、批次统计、coverage、失败股票和全部独立 signals；同一
+  股票同日的多 category 不能合并，并按 `ZHIXING_B1_SIGNAL_ORDER` 稳定排序。
+- 前端仅在首次无结果时直接触发；已有终态结果或失败重试必须先确认，再传
+  `rerun=true`。运行中重复请求返回冲突，不能创建第二个当前 run。
+
+### 4. Validation & Error Matrix
+
+| 条件 | 行为 |
+| --- | --- |
+| 不支持的策略、非法日期或缺少合格市场数据 | `422`，错误码 `market_data_not_ready`（输入校验仍使用 FastAPI 默认 `422`） |
+| 同策略同日已有 `running` run | `409`，错误码 `run_in_progress` |
+| 已有终态 run 且 `rerun=false` | `409`，错误码 `rerun_confirmation_required` |
+| PostgreSQL 读写失败 | `503`，错误码 `selection_storage_unavailable` |
+| run ID 不存在 | `404`，错误码 `run_not_found` |
+| 单只股票评估抛出异常 | 记录该 item 为 `data_error`，继续其他股票；批次最终为 `partial_success` 或 `failed` |
+| 全股票评估完成但没有命中 | 批次为 `success`、`signal_count=0`；前端显示“没有命中信号”，不是“无数据” |
+
+### 5. Good / Base / Bad Cases
+
+- Good：目标日已有合格同步批次，首次 POST 返回 `202`，轮询最终结果保留同一股票的
+  两个独立 category；确认重跑后旧 signals 随旧 run 级联清除。
+- Base：目标日没有结果时查询返回 `200 status=no_data`；查询不触发公式计算，用户可在
+  页面选择日期后发起首次执行。
+- Bad：在市场数据预检前删除旧 run；把多个 category OR 成一条 signal；用浏览器长连接
+  等待全股票池计算；或把进程异常留下的 `running` 伪装成成功。
+
+### 6. Tests Required
+
+- Domain/application：断言 source 预检先于 `prepare_run`、首次执行、多分类落盘、单股异常
+  继续执行、全部 no-signal 和失败计数/终态聚合。
+- PostgreSQL adapter：用 fake connection 断言 advisory lock、终态重跑删除后插入、运行中
+  冲突、JSONB details、级联删除契约和公式优先级排序。
+- HTTP：用 `TestClient(create_app())` 断言 `202`、`409` 两类冲突、`422` 数据未就绪、
+  `GET` 无数据、run 轮询和终态 signals。
+- Migration：在可用 PostgreSQL 中断言三张 selection 表、唯一键、索引、cascade 外键，
+  并验证 downgrade 顺序；无数据库时至少生成 offline upgrade/downgrade SQL。
+- Frontend：断言加载、查询失败、无数据、执行中、失败、部分成功、无命中、多 category，
+  以及重跑/失败重试确认取消不发 POST、确认发送 `rerun=true`。
+
+### 7. Wrong vs Correct
+
+#### Wrong
+
+```python
+# 先清空旧结果，再去确认目标日输入是否可执行；预检失败会造成数据丢失。
+store.delete_current(strategy, target_trade_date)
+source = reader.load_execution_source(strategy, target_trade_date)
+```
+
+#### Correct
+
+```python
+# 先读取并验证来源快照，只有成功 claim 后才允许重跑清理事务。
+source = reader.load_execution_source(strategy, target_trade_date)
+run = store.prepare_run(strategy, target_trade_date, source, rerun=rerun)
+```