docs(ui-automation): 会话48 看门狗失败无报告修复完成并部署三台，同步 HANDOFF 与执行计划/问题处理文档状态

Co-Authored-By: Claude <noreply@anthropic.com>

Docs/PRD/问题处理/执行中心/_问题处理_定时任务看门狗失败执行无报告输出.md

+# 问题处理文档 - 定时任务看门狗失败执行无报告输出
+
+> **文档类型**: 问题处理文档
+> **创建日期**: 2026-09-01
+> **作者**: czj
+> **优先级**: P0
+> **状态**: 已修复（待部署）
+
+---
+
+## 一、问题描述
+
+### 1.1 现象
+
+5.44 测试管理平台「每日定时自动化测试」任务每次执行的**执行中心均无报告输出**。
+
+- 用户在 5.44 平台执行中心查看 `exec_24b3a3291eb64760ae6045ae9ea1e198`（09-01 01:25:41 触发）：
+  状态 = **failed**，error_message = *"执行长时间无进展，看门狗判定执行线程异常退出，自动标记为失败"*，
+  **报告入口缺失**，容器内 `/app/data/reports/` 无 `report_exec_24b3a329_*.html` 文件。
+
+### 1.2 复现范围（非偶发）
+
+近 8 条「每日定时」任务执行的执行结果（全部无报告）：
+
+| 执行 ID | 开始 | 结束 | 结果 |
+|---|---|---|---|
+| exec_ef66c19a | 08-31 14:34 | 08-31 19:29 | ❌ 看门狗 failed（~4.9h） |
+| exec_0ba3d399 | 08-31 20:35 | 09-01 01:25 | ❌ 看门狗 failed（~4.7h） |
+| exec_24b3a329 | 09-01 01:25 | 09-01 06:09 | ❌ 看门狗 failed（~4.7h） |
+| exec_fd29f4fe | 09-01 06:09 | 运行中… | ⏳ 本次执行中 |
+
+每次执行约 4~5 小时后被看门狗判定失败，**连续 4 次失败、0 次报告输出**。
+
+### 1.3 影响范围
+
+- 每天多次定时执行**全部无报告可看**，失败原因无法在报告中心呈现
+- 定时任务形同虚设：用户无法通过报告中心查看任何一次执行结果
+
+---
+
+## 二、根因分析
+
+### 2.1 报告生成条件（代码根因）
+
+`backend/app/services/scheduler_service.py` 中 `run_task_once()`：
+
+```python
+# 4. 运行执行（阻塞等待完成；内部全局锁保证串行）
+run_ok = True
+try:
+    await exec_service.run_execution(execution.id)
+except Exception as e:
+    run_ok = False
+    logger.error(...)
+
+# 5. 自动生成报告（执行成功后才生成）
+if task.auto_report and run_ok:
+    → generate_html + save_report
+```
+
+**`run_ok` 仅在 `run_execution()` 正常返回、不抛异常时为 True。**
+
+当看门狗判定执行「长时间无进展」时：
+
+1. `execution_service.watchdog_scan_once()` 将 executions 表该记录置为 **failed**（`duration=0`，写入看门狗 error_message），并把剩余 pending/running 的 case_results 批量置 failed；
+2. 工作线程已被中断，`run_execution()` 提前返回/抛异常；
+3. `scheduler_service` 中 `run_ok=False` → **报告生成被跳过**。
+
+### 2.2 既有数据可行性（修复依据）
+
+执行被看门狗标记失败时，**213 条 passed / 95 条 failed 用例结果已实时写库**（`_persist_case_result` 逐条 commit），仅剩 24 条 pending 被批量置 failed。`ReportService.generate_html()` 只读取 `case_results` 表渲染，**failed 执行同样能输出完整结果页**。
+
+### 2.3 卡死点排查结论（B 并行排查）
+
+| # | 结论 | 证据 |
+|---|------|------|
+| 1 | 每次执行都在「信息发布/消息通知」之后卡住，最终被看门狗标记 | 24b3a 最后一条完成 = 信息发布-页面访问验证 05:51:35；其后 24 条 pending 批量置 failed（下载列表/通讯录/预定数据/信息管理/门口屏发布等） |
+| 2 | **case_results.start_time 从未写入**（`_persist_case_result` 只写 end_time）| 全表 start_time 为 NULL → 无法精确定位卡死的那条用例 |
+| 3 | 容器日志早于 8-29 已轮转，9-01 卡死时段无日志可取证 | `docker logs` 仅含 8-29 内容 |
+| 4 | 历史日志可见 Chromium **页面崩溃高频**（`Page crashed`/`Target crashed`/`Target closed`）| 8-29 日志 "导航到主页失败（不影响后续执行）: Page crashed"、"步骤 1 尝试 1/3 失败... Target crashed" |
+| 5 | 当前执行 fd29f4fe 健康（30 分钟产出 41 条结果），非全链路卡死 | DB 实况 |
+| 6 | 执行无「单用例超时兜底」：Playwright 在 tab 崩溃/页面无响应场景下，`evaluate`/`goto` 可长时间挂起 | `playwright_executor.py` 各操作 timeout 均为单步超时（默认 30s），无整用例上限 |
+
+**卡死根因推断**：执行长跑 4~5 小时后 Chromium 页面/tab 崩溃或目标系统页面无响应，某用例交互操作在崩溃态下挂起且无整用例超时兜底 → 30 分钟无任何进展 → 看门狗判定 failed。需要后续专项治理（见计划执行文档 B 部分）。
+
+---
+
+## 三、修复方案
+
+**A 修复（本次已实施）**：看门狗失败执行也生成报告。
+
+修改 `scheduler_service.py`：
+
+1. 新增 `_has_any_case_results(db, execution_id)` 辅助函数——查询该执行是否已产生任何用例结果；
+2. UI 与 security 两条路径的报告生成条件由
+   `task.auto_report and run_ok`
+   改为
+   `task.auto_report and (run_ok or await _has_any_case_results(db, execution.id))`。
+
+效果：执行被看门狗标记 failed 但已有结果时，自动生成报告（默认渲染完整结果页），失败执行不再"静默无报告"。
+
+**B 后续治理（本次仅排查，未改码）**：定位并消除卡死点，见计划执行文档。
+
+---
+
+## 四、验收标准
+
+| 测试项 | 预期结果 |
+|--------|----------|
+| 定时任务执行成功 | 正常生成报告（行为不变） |
+| 定时任务被看门狗标记失败（已有用例结果） | 自动生成报告，含已执行用例的通过/失败明细 |
+| 定时任务启动即异常、无任何用例结果 | 不生成空报告（保持原守卫） |
+| 手动「立即执行」触发 | 报告生成行为不变（仅影响定时任务） |
+
+---
+
+## 五、相关文件
+
+- `backend/app/services/scheduler_service.py` — 报告生成条件（A 修复改动点）
+- `backend/app/services/execution_service.py` — 看门狗逻辑（`watchdog_scan_once`，B 排查对象）
+- `backend/app/services/report_service.py` — HTML 报告生成（只读 case_results，失败执行可渲染）
+- 容器报告目录：`/app/data/reports/`（宿主机路径独立，非 `/data/third_party/...`）
+
+---
+
+*本文档由 Claude Code 生成，遵循项目问题处理文档规范。*
\ No newline at end of file