docs: PLAN 附录 F 补记 PC-2 与 A37(测试规模 1697/86 + e2e 14)

This commit is contained in:
thzxx
2026-09-15 01:22:16 +08:00
parent 567d150257
commit 0c5c0b1d20
+17 -9
View File
@@ -717,6 +717,8 @@ connection-manager/integrations/migration)两份完整报告,以及测试质
| `b20d47b` | **B-3 单管线** | QueryBuilder 只产出 AST、执行一律经 Executor(删除无 JOIN 时直通 `engine.find` 的快路);钩子改为由 `Table` 注入、顺序与传参不变;删除引擎层 4 处"未解析标记 → NOT_SUPPORTED"的过时防御 |
| `edd9f1d` | **B-6 ①②(两处 P0** | ① `open()` 遇损坏日志尾部不再**清空整库**(新增 `truncateLogTo(keepBytes)`,与 `repair()` 同口径);② 自动 checkpoint 失败不再让**已确认写入**报错(WAL 已持久化),改为记 `lastBackgroundError` 并由下一次显式 `checkpoint()` 报告 |
| `68e4731` | **B-6 ③ + 测试介质** | ③ meta 增加 `owner`,陈旧实例 `checkpoint()``STALE_INSTANCE` 拒绝覆盖新实例的写入(实测修复前会**静默**抹掉);同时修复 `SharedMemoryBackend` 的跨实例可见性缺陷(私有拼接缓存使介质退化为"每实例一份快照",此前所有多实例用例都跑在错误介质上) |
| `6a0cfeb` | **PC-2 真崩溃注入** | e2e 的 `crashPage()` 原本只是 `win.__ms = null; page.close()` —— **优雅关闭**,所有"崩溃恢复"用例测的其实是"正常关闭后重开"(CI 注释却声称覆盖 CDP `Page.crash`)。现改用 CDP `Page.crash` 终止渲染进程,并新增两个真实窗口:`createWritable().write()` 中途、`close()` 原子替换前(copy-on-write 的核心不变量)。实测要点:崩溃后 `page.isClosed()` 仍为 falseOPFS 数据在同 context 内跨崩溃保留 |
| `567d150` | **A37 列引用** | 未限定列可作比较操作数(`WHERE x = y` / `ON k = k` 此前 PARSE_ERROR,列对列比较被迫写限定形态);新增 WHERE / JOIN ON 的列存在性校验 —— `$col` 引用不存在的列此前**静默返回空集**(`WHERE id = oops``[]`),现报 `COLUMN_NOT_FOUND`;顺带解除 `schema ↔ validation` 循环依赖 |
### 三值逻辑根治(A15 / PB-2,提交 `4ab04df`
@@ -795,18 +797,24 @@ connection-manager/integrations/migration)两份完整报告,以及测试质
| ~~P0~~ | ~~**B-3 单管线**builder 只产出 AST~~ | ✅ `b20d47b` |
| ~~P0~~ | ~~**B-6 KVStore 三处止血**~~ | ✅ `edd9f1d` + `68e4731` |
| P1 | A13/A14 自引用外键失效、ON UPDATE CASCADE 只一层 | 待做 |
| P1 | A35/A37 JOIN NULL 键(已修)、未限定列名(PARSE_ERROR 显式拒绝) | 部分 ✅ |
| ~~P1~~ | ~~A35 JOIN NULL 键~~ | ✅ `841db2e`(JOIN 的 NULL 键不成立,且与右表有无索引无关) |
| ~~P1~~ | ~~A37 未限定列名 / WHERE 列存在性~~ | ✅ `567d150` |
| P1 | A38/A39 `compression` 被 pageStorage 遮蔽、`compressLZ4` O(n²) | 待做 |
| P1 | A40/A41 Aria `close()` 活跃事务守卫、`dropTable` DDL 原子性 | 待做 |
| P0 | **B-6 存储单一提交点(manifest** | 部分(KVStore 已完成;Aria 见 A40/A41 |
| P1 | **B-4 统一表达式求值器**(CASE 正则切分、聚合表达式、列引用) | 待做(A25 已先修其载体 |
| P0 | **B-6 存储单一提交点(manifest** | 部分(KVStore 三处止血已完成;Aria 见 A40/A41 |
| P1 | **B-4 统一表达式求值器**(CASE 正则切分、聚合表达式、列引用) | 部分(聚合与列引用已统一,见文末说明 |
| P1 | **B-5 结构化 AST 表达式节点 + 输出列序号** | 待做 |
| — | PC-2 e2e 真崩溃注入(CDP `Page.crash` | 待做 |
| ~~—~~ | ~~PC-2 e2e 真崩溃注入(CDP `Page.crash`~~ | ✅ `6a0cfeb`14 项 e2e,含两个 OPFS 写入窗口) |
| — | PC-4/PC-5 契约测试 + 属性测试 | 部分(跨引擎参数化已用于 A1/A2/A15/B-1/B-3 |
| — | PG 文档与站点全量同步 | 待做 |
**下一步建议**PC-2 真崩溃注入(e2e 通过 CDP `Page.crash`,覆盖"写入未 await
即崩溃 / checkpoint 中途崩溃 / WAL 半写"三个窗口)—— 这是**验证**已完成的
崩溃语义声称的关键一步,目前所有崩溃结论都来自单元级故障注入;
随后 B-4(统一表达式求值,消除 CASE 正则切分整类)→ A13/A14(外键传递闭包)
→ A38~A41(存储层剩余)→ B-5 → PG。
**下一步建议**A13/A14(外键传递闭包:自引用外键与多层 ON UPDATE CASCADE
→ A38/A39`compression` 被 pageStorage 遮蔽、`compressLZ4` O(n²))→ A40/A41
Aria `close()` 活跃事务守卫、`dropTable` DDL 原子性)→ B-4 统一表达式求值
(CASE 正则切分整类)→ B-5 结构化 AST → PG 文档与站点同步。
**关于 B-4/B-5 的现状**:二者的"载体"已在其他修复中先行落地 ——
`parseAggregateExpression` / `resolveColumnValue`B-4 的聚合与列引用部分)、
`sqlCompare`/`encodeValueKey`(统一值语义)、`normalizeUnprefixedReferences`
(统一引用归一化)。剩余部分(CASE 的正则切分、输出列序号)影响面小于
A13/A14 与 A38~A41,故排序在后。