64 lines
2.7 KiB
Markdown
64 lines
2.7 KiB
Markdown
## Context
|
||
|
||
当前系统采用 `success` + `matched` 两层判定模型：
|
||
- `success`：拨测是否成功完成（HTTP 收到响应 / Command 正常退出）
|
||
- `matched`：expect 规则是否匹配
|
||
- UP = `success AND matched`
|
||
|
||
但实际代码中 `fetcher.ts` 和 `command-runner.ts` 均将 `success` 设为 `expectResult.matched`，导致 `success ≡ matched`。两层模型从未真正生效，`success` 字段是冗余的。
|
||
|
||
同时发现两个附带问题：
|
||
1. 分组排序使用 `ORDER BY grp`（字母序），spec 要求按 YAML 首现顺序
|
||
2. `command-runner` 未设置 `stdin: "ignore"`，spec 要求禁止写入 stdin
|
||
|
||
## Goals / Non-Goals
|
||
|
||
**Goals:**
|
||
|
||
- 移除 `success` 字段，将判定模型简化为 `matched` 单层判定
|
||
- 修复分组排序为 YAML 首现顺序
|
||
- 确保 command-runner 禁用 stdin
|
||
|
||
**Non-Goals:**
|
||
|
||
- 不涉及 `success` 以外的其他字段变更
|
||
- 不涉及前端 UI 样式或布局调整
|
||
- 不涉及新增功能特性
|
||
- 不处理代码质量问题（P2/P3 级别留给后续 change）
|
||
|
||
## Decisions
|
||
|
||
### 1. 判定模型简化为 matched 单层
|
||
|
||
**选择**: 移除 `success`，仅保留 `matched`
|
||
|
||
**理由**: `success` 与 `matched` 在实现中始终同值，没有独立语义。执行失败（网络错误、超时、进程崩溃）和 expect 不匹配都统一为 `matched=false`，通过 `failure.kind` 区分（`"error"` vs `"mismatch"`）。
|
||
|
||
**替代方案**: 修复 `success` 使其真正独立（如 HTTP 返回 404 时 success=true, matched=false）。被否决——当前项目不需要区分"请求成功但内容不符"和"请求失败"，单层判定更简洁。
|
||
|
||
### 2. 可用率计算基于 matched
|
||
|
||
**选择**: `availability = matched=true 的记录数 / 总记录数 * 100`
|
||
|
||
avgDurationMs 仅计算 `matched=true` 记录的平均耗时：`AVG(CASE WHEN matched = 1 THEN duration_ms END)`
|
||
|
||
**理由**: 用户关心的是"健康请求"的性能趋势，排除失败请求的干扰。
|
||
|
||
### 3. 分组排序改为按 id 排序
|
||
|
||
**选择**: `ORDER BY CASE WHEN grp='default' THEN 0 ELSE 1 END, id`
|
||
|
||
**理由**: 目标按 YAML 顺序插入，`id` 自增，`ORDER BY id` 天然等于 YAML 首现顺序。无需额外存储排序权重。
|
||
|
||
### 4. 数据库迁移策略
|
||
|
||
**选择**: 直接删除旧数据库文件重新创建
|
||
|
||
**理由**: 项目未上线，无向前兼容要求。SQLite 不支持 `DROP COLUMN`（需重建表），直接删除是最简方案。
|
||
|
||
## Risks / Trade-offs
|
||
|
||
- [风险] 数据库 schema 变更导致已有数据丢失 → 项目未上线，可接受
|
||
- [风险] 前端 API 响应格式变更 → 前端代码同步修改，全量测试覆盖
|
||
- [风险] 大量文件同时修改可能引入遗漏 → 通过 `bun run verify` 全量验证
|