MetonaSqlark

Files

T

thzxx bf93ec5251 fix(A41): DDL 的 WAL 意图必须先于生效 + ALTER 结构变更可崩溃恢复（A40 未复现，固化为护栏）

实测确认的缺陷：**DDL 的 WAL 意图记录写在生效之后**，而 WAL 是崩溃后唯一能重放
的结构权威 —— 于是它恰恰是最后才写的：
  - `dropTable('other')` 删完 LSM 与 schema 后崩溃（WAL 尚无 DROP 记录）
    → 重开 `tables = ["t","other"]`，且 other 的行数据完好：**DROP 被静默撤销**
    （用户以为删掉了）；
  - `alterTable` **完全不写 WAL**：先改内存 schema、必要时建索引（可能因存量
    重复值抛错），最后才 persistSchemas —— 中间抛错就留下"内存已加列、磁盘没加"
    的分裂状态，崩溃则结构变更整体丢失。
    变异验证：去掉 ALTER 回放后，`ADD tag` + `ADD tag2` 两列在重开后**都消失**
    （实测 `after reopen columns: ["id"]`）。

修法（结构上唯一正确的顺序）：
  **先写 WAL 意图并刷盘 → 再改内存 → 最后落盘 schema**
WAL 回放是幂等的（CREATE 对已存在的表跳过、DROP 对不存在的表是空操作、
ALTER 用变更后的完整 schema 覆盖），因此先写 WAL 一定能收敛：
崩溃于 WAL 之后生效之前 → 重放生效；崩溃于生效之后 → 重放幂等。
新增 `WALRecordType.ALTER_TABLE = 10`（含变更后的完整 schema）与统一入口
`appendDDLRecord`（两条 DDL 路径共用顺序与刷盘策略，避免再次单点漂移）。

测试可观测性：`AriaEngine` 无法注入存储后端 —— 而 `this.backend` 在 `open()`
里被 WAL、FileManager、SSTableStore 一起捕获，事后替换只会替换一部分
（实测：替换后 WAL 仍写旧后端，于是"崩溃"根本没覆盖 WAL 路径，探针得出假结论）。
新增 `AriaEngineConfig.testBackend`（仅测试用）作为注入点。

关于 A40（审计记录为"close() 截断 WAL 并把未提交写入落盘 → 重开后幽灵行"）
经探针**未复现**：事务中 close 后重开只看到已提交行；事务中 DDL 抛
NOT_SUPPORTED；close 后 rollback 抛 TX_NONE；二次 close 幂等。
按项目原则不"修"不存在的问题，而是把这些**已正确**的行为固化为护栏。

验证：新增 tests/v080-aria-ddl-atomicity.test.ts（11 项：4 项顺序不变量、
4 项崩溃恢复、3 项生命周期护栏）。顺序断言用"记录持久化顺序的后端"实现 ——
那是**顺序**性质，OPFS mock 只暴露最终状态，测不出来。
四处修复均做变异验证。全量 89 套件 / 1752 测试通过；typecheck、lint、build
零错误零告警；dist 已重建。

2026-09-15 02:20:27 +08:00

e2e

test(PC-2): e2e 真崩溃注入（CDP Page.crash）取代假崩溃 + 两个 OPFS 写入窗口

2026-09-15 01:06:23 +08:00

engine

fix(A38/A39): 页面化路径真正压缩 + compressLZ4 去除二次复杂度（含测试介质目录语义修正）

2026-09-15 01:52:57 +08:00

helpers

fix(A38/A39): 页面化路径真正压缩 + compressLZ4 去除二次复杂度（含测试介质目录语义修正）

2026-09-15 01:52:57 +08:00

hybrid

fix(A8 + LSM 读自洽): 行所有权根治 + 读取路径不再依赖 prefetch