admin
c1b5e4d966
- 变更规模：新增 514 / 修改 62 / 重命名 155 / 删除 4（归档重组与文档轮次） - .gitignore 修：`归档/**/db-cwd归一-备份-*/` —— 原规则写绝对层级（归档/db-cwd归一-…）， 目录搬进 归档/配置与备份/ 后**静默失效**，43 MB 的 DB 备份又变成未跟踪 - .gitignore 补：嵌套 git 内部数据（归档/内嵌git-20261008/、归档/skills-git-旧线-20261007/dotgit-原样移出/） - .gitignore 补：运行态与部署副本（.workbuddy/collab/、.workbuddy/tools/、.workbuddy/.load-pending、.workbuddy/tmp-*） - .gitignore 补：备份件（*.bak-*） - 未跟踪文件从 2190 降到 890（其余为 归档/ 归档件与 .workbuddy/memory/ 知识文件，按口径入库）
51 lines
5.4 KiB
Markdown
51 lines
5.4 KiB
Markdown
# 排期「哑火」真因取证与堆积治理（2026-10-02 14:16–14:2x）
|
||
|
||
- 承办：`[协作]-[机制排查与修复]-承接队列`（`e0b9622a`，本类别在跑的协作会话）
|
||
- 承接件：`[协作]-[机制排查与修复]-排期哑火与堆积治理`（原排期 `45975f61`，一次性 14:15）—— 本会话即同线同类别的活棒，按「每条线只挂一个排期」接手其任务，该排期已删（见文末「本棒动作」）
|
||
- 取证方式：**只读**打开宿主库（`file:…workbuddy.db?mode=ro`），⛔ 未写宿主库
|
||
- 取证脚本：`tmp/_misfire_probe_20261002.py`、`tmp/_misfire_probe2_20261002.py`
|
||
|
||
## 一、结论（三句）
|
||
|
||
- **「到点未触发」不等于哑火**：一次性排期在本机**不是到点即时触发**，而是由主机轮询/唤醒时补跑（运行记录里标 `runKind=missed`）⇒ 实测延迟 **2.0 / 5.2 / 5.8 / 8.8 / 9.7 分钟** 不等。
|
||
- **体检报告里那条「哑火」是假红**：`717cd210`（`[协作]-[会话协作自检]-S7 全量验收 V1–V7`，计划 13:42:00）**实际跑了** —— 实跑 13:42:15（延迟 15 秒，`runKind=scheduled`），并产出会话 `053acd9e`（`completed`）。体检只看「到点 sessions 里有没有新会话」、没给补跑容差 ⇒ 误判。
|
||
- **真哑火只有一条**：`87d55715`（`[协作]-[会话协作自检]-S7 全量验收 V1–V7 并如实报告`，计划 10:52，距今 210 分钟，`automation_runs` **无任何记录**）—— 且同名任务已由 `717cd210` 覆盖完成 ⇒ **无实际损失**。
|
||
|
||
## 二、三问三答（承接件点名要回答的）
|
||
|
||
### 1、`ACCEPTED` 但 `started_at` 为空代表什么？
|
||
|
||
**代表「真跑了」**，不是「只入队没执行」。反查 `sessions` 表即可证（今天 12:00 之后的全部 run 逐条核对）：
|
||
|
||
- `717cd210` run `ACCEPTED ok=1 kind=scheduled` ⇒ sessions 命中 `053acd9e`「[协作]-[会话协作自检]-S7 全量验收 V1–V7」`completed`（建于 13:42:15）
|
||
- `59ee239b` run `ACCEPTED ok=1 kind=missed` ⇒ sessions 命中 `d29b01c8`「[跟进]-队列上报（固定席位·不分类别）」`completed`（建于 14:08:03）
|
||
- `e0b9622a` run `IN_PROGRESS kind=missed` ⇒ sessions 命中「[协作]-[机制排查与修复]-承接队列」`working`（建于 14:16:12，**即本会话**）
|
||
|
||
⇒ **判据（可复用）**：`automation_runs.metadata_json.conversationId` 能在 `sessions` 表命中 ⇒ 真拉起；`ACCEPTED` 只是投递回执，⛔ 不能单独当「有没有跑」的证据；`started_at`／`finished_at` 在本机**不被维护**（全为空），⛔ 同理不可作证。
|
||
|
||
### 2、已过点的一次性排期为什么没被清掉、也没再触发？
|
||
|
||
- 一次性排期跑完后 `status` 仍为 `ACTIVE`、`next_run_at` 保持 `None` ⇒ **`next_run_at=None` 的确切含义是「没有下一次」，不是「未调度」**。
|
||
- 主机不会回收它 ⇒ 于是越堆越多。实测在册一次性排期 **31 条**，其中 **26 条已有运行记录（跑完了）却仍挂着 ACTIVE**，最早可追到 10-01 09:10。
|
||
- 附带影响：每条陈旧排期都会进「缺口/在途」计算与体检扫描，把「在途」读数灌水 —— 这正是 14:16 那版体检/摘要「在册 7 条都不活」这类判读失真的来源之一。
|
||
|
||
### 3、治理建议（⛔ 本棒只写建议，清理动作留给下一棒/用户点头）
|
||
|
||
1. **清理已跑完的一次性排期**（26 条）：判据 = `schedule_type=once` ∧ `automation_runs` 有记录 ∧ 距今 > 30 分钟。保留：周期排期（AI 变现日报／决策线体检／日志清理）、未跑的一次性排期、真哑火待决的 `87d55715`。
|
||
2. **体检「哑火」判据加补跑容差**：改成「计划时间已过 **≥15 分钟** 且 `automation_runs` 无任何记录」才算哑火；命中补跑（`runKind=missed`）的一律改写为「延迟 N 分钟」，⛔ 不喊哑火。
|
||
3. **派棒不要挤在同一分钟**：本轮 14:11 / 14:14 / 14:15 三条一次性排期扎堆，撞上「~5 分钟补跑延迟」就会互相看成「在途」，建议间隔 ≥10 分钟。
|
||
4. ⛔ **不要在排期上改时间复用**：对已有一次性排期 `update` 改 `scheduledAt` 不会被重新调度（前棒实测），要改就新建、旧的删掉。
|
||
|
||
## 三、关于「本类别唤醒会话 0 条」（S7 验收 V7 点名的线索）
|
||
|
||
- 核实结论：**不是缺陷，是正常态**。看板口径写明唤醒会话「**随需求确定时创建** ⇒ 圆角矩形＋外圈虚线，『还没建』＝**正常态**」；V7 原文也只标注「属该类别缺口，**不判本项 fail**」。
|
||
- 本类别当前任务图 S1–S9 全 done、队列 `head=null / pending=0` ⇒ **没有需要唤醒的待办** ⇒ 0 条在册符合预期。⛔ 不为此建会话/排期（建了反而造成排期堆积，与本文治理方向相悖）。
|
||
|
||
## 四、本棒动作（可核对）
|
||
|
||
- 取证并落本文件（`交付物/排期哑火真因与堆积治理-20261002.md`）。
|
||
- 任务图 `交付物/任务图-会话协作自检.json` 新增：`S10`（本件，line=机制排查与修复，`done`）、`S11`（判据修复＋清理，`todo`，deps `S10`）。
|
||
- 同线重复棒 `45975f61`（`[协作]-[机制排查与修复]-排期哑火与堆积治理`）已删除 —— 它的活由本会话做完，留着会再开出一条同线会话互抢锁。
|
||
- 派下一棒：`[协作]-[机制排查与修复]-哑火判据与排期清理`（S11）。
|
||
- ⛔ 未 commit、未 push、未改 `goal.json` 的 `topics`/`title`/`lines`、未起常驻后台任务、未写宿主库。
|