MetonaTeam/MetonaSqlark
2
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
121 Commits 1 Branch 0 Tags
c1c3036abdbe7b9bf78344ab7a3caf4008fb743b
Commit Graph
11 Commits
Author SHA1 Message Date
thzxx c1c3036abd fix(site/v0.8.0): 站点版本同步 + 现场失败修复（file:// 打不开 OPFS 的可操作错误） 
用户报告"站点演示失败了"，实测复现并定位根因：

- 现象：直接双击 site/demo.html（file://）→ 点「🌲 Aria」→
  "❌ 数据库初始化失败: Failed to open AriaEngine database "demo""（Memory 正常）。
- 根因：file:// 属不透明来源，Chromium 拒绝 navigator.storage.getDirectory()
  并抛 SecurityError；此时 isSecureContext 仍为 true、API 也存在，无法提前探测。
  引擎把它包成 ARIA_OPEN_ERROR 时丢掉了底层错误 → 消息对用户不可操作。
- 修复：OPFSBackend.open() 显式检查并抛 ARIA_OPFS_UNAVAILABLE，消息给出两条出路
  （用 http(s) 打开 / 改用 mode:'memory'），原始 SecurityError 挂 cause；
  site/demo.html 额外用中文说明"为什么失败 + 怎么修"。

顺带修掉一个更普遍的问题：DatabaseError 的第三个参数只进 details，err.cause
恒为 undefined，而文档/注释多处写"底层错误作为 cause 保留"。现在两者都成立
（details 语义不变；cause 声明为公开字段并接入标准错误链）。

站点版本同步：demo.html（title / 状态栏 / SQL 预置脚本 / console 日志）与
benchmark.html（title）此前仍是 v0.7.4（日志甚至是 v0.4.2）→ 统一 v0.8.0；
docs.html 的 AriaEngine 版本演进列表补上 v0.8.0 条目、错误码表补
ARIA_OPFS_UNAVAILABLE；README 补"OPFS 需要 http(s) 页面"的浏览器兼容说明。

回归与门禁：tests/engine/aria-opfs-unavailable.test.ts（5 项，含正常环境正控）；
变异 R19 / R20 均被拦住（总计 42/42）；93 套件 / 1985 用例；覆盖率
90.59 / 82.61 / 94.14 / 93.50（阈值 90/82/94/93）；e2e 14/14；lint + 两份 tsc 干净；
dist 重建（251,731 B / gzip 63,431 B）并已同步全部体积宣称。
 2026-09-15 17:09:29 +08:00
thzxx 0b44620721 fix(v0.8.0): 全量回归审查 —— 1 处 P0 数据丢失 + 4 处 P1 + 9 处 P2 根因修复 
方法：四个对抗性子代理分头审查（数据正确性 / 文档宣称 vs 实现 / 公共 API 契约 /
测试质量），每条结论要求可复现证据；逐条复核 + 探针确认 + 变异验证（40 项全部
被对应用例拦住）。

P0：事务活跃期间 repair()/close()/周期 checkpoint 推进 WAL 水位 → 已 COMMIT 的
事务整批消失且恢复报告"干净"。根因 hasPendingFlushData()/computeDurableLsn()
不看 txnSnapshot；守卫此前只在 CheckpointManager 两个回调里。修复：守卫下沉到
computeDurableLsn() 与 advanceWalCheckpoint() 入口（唯一实现）。

P1：
- WAL 前缀缺失丢弃整段活分片（回退上一代 manifest 时 kept 为空）→ 前缀缺失单独
  记录，后缀照常重放；仅 fromLsn === 0 时才算真异常
- 孤儿回收门槛只看引擎层 dataLossSuspected，漏掉 LSM 层被丢的 SSTable →
  统一 describeRecoveryDamage() 聚合判定（损坏时绝不删"引用不到"的文件）
- vacuum() 逐层压缩绕过维护链 → vacuumLevels() 每层作为维护链任务执行
- reclaimRetiredNow() 无视在途读者（读者把"已退休"读成"文件损坏"）→ 有读者时
  退化为延迟回收

P2：WAL 记录级 CRC 损坏不计数不上报；旧格式表结构记录形状损坏静默当空库；
bloomFilterBitsPerKey 配置被接受却完全不生效（构建器写死默认值，实现缺陷）；
幽灵 meta；介质读故障等于文件损坏的语义无用例；manifest 回读校验两条守卫无用例；
文件名≠载荷世代判定无用例；pageIdWatermark 单调性无用例；分片号两条真实不变量
无用例。

覆盖率口径（第二处漏洞）：interface.ts 混着三个运行时函数（cloneRow 等）却被
描述为"纯类型、不纳入统计" → 实现搬到 src/engine/row_clone.ts；搬完门禁真的
失败（functions 93.84% < 94%），补测退化路径后通过。

测试质量：3 条空壳用例改值级断言；1 条"全损坏"用例实际只走缓存 → 拆成两条真
用例；5 秒墙钟 race 改门控 + 失败上限；setTimeout 改 whenIdle()；<= 收紧为 <。

变异脚本加固：正控（干净基线必须全绿）、编译失败/0 用例单独归类、300s 超时、
逐字节 sha256 恢复校验、O_EXCL 进程锁、锚点唯一性；变异 22 → 40 项。

文档两轮订正（16 + 11 条不成立宣称）：MVCC 快照隔离、backup 一致性快照、
"空洞检测截断"、体积（251,109 B / gzip 63,145 B）、测试与覆盖率数字、
"5 种存储引擎"、Tree-shakable、错误码表补 16 个码、恢复报告字段、已知限制
（回退单向 / 多实例依赖 Web Locks / manifest 体积 / 尾部 WAL 分片不可识别）。

验证：常规套件 92 套件 / 1980 用例全绿；覆盖率 90.59 / 82.59 / 94.14 / 93.50
（阈值 90/82/94/93）；e2e 14/14（真实 Chromium + OPFS + CDP 崩溃）；
重型套件 4 套件 / 27 用例；变异 40/40；lint + 两份 tsc 干净；dist 已重建。
 2026-09-15 16:33:40 +08:00
thzxx 81c46eb6f2 docs(B-6): 附录 H（B-6 完整实施记录）+ README/CHANGELOG/site/CONTRIBUTING 同步 
- PLAN 附录 H：交付物清单、提交顺序不变量、**实施中新发现的 10 个缺陷**（含分片号复用、
  读快照与并发 flush 的窗口、checkpoint 仍等 compaction、takeover 世代竞争、提交中冻结表
  误报 WRITE_LOST、底部层只剩墓碑的 TypeError、介质读故障被当缺失、元数据损坏静默空库等），
  以及可复现的验收命令与实测数字。
- PLAN 待办表：B-6 行改为"完整实施（非降级选项）"；原"B-1 遗留"给出结论
  （compaction/merge 输入只来自已校验数据，补校验反而有害；触发条件写明）。
- README：架构图/核心机制加入单一提交点；新增"存储布局在 v0.8.0 变更"的已知限制与迁移说明；
  测试 1935 / 覆盖率 90.34 · 82.16 · 94.06 · 93.23；新增变异验证命令。
- CHANGELOG：0.8.0 条目补齐 B-6 完整实现（含 9 个新错误码与恢复报告）。
- site：错误码表补 7 个新码；AriaEngine 与崩溃恢复卡片按实现改写（不再宣称"空洞截断"）；
  首页徽章数字同步。
- CONTRIBUTING：新增"变异验证"一节（修复类提交必须能回答"回退后用例会不会失败"）。
 2026-09-15 10:29:09 +08:00
thzxx 34efde701c docs: PLAN 待办表与下一步方向同步至 v0.8.0 完成状态 2026-09-15 08:06:50 +08:00
thzxx 61a165be7c docs(G6): 补录附录 G —— G1~G6 硬门禁验收记录（含可复现命令与实测结果） 2026-09-15 08:06:40 +08:00
thzxx 2328540779 docs: PLAN 附录 F 补记 A13/A38/A39 与验证基础设施（测试规模 1742/89） 2026-09-15 01:53:08 +08:00
thzxx 0c5c0b1d20 docs: PLAN 附录 F 补记 PC-2 与 A37（测试规模 1697/86 + e2e 14） 2026-09-15 01:22:16 +08:00
thzxx a753c7ff55 docs: PLAN 附录 F 更新至 B-1/B-3/B-6 与查询层 8 项修复（测试规模 1686/87） 2026-09-15 00:35:02 +08:00
thzxx 67e72d897f docs: PLAN 附录 F 记录 A9/A10/A15 完成情况与三值逻辑根治细节 2026-09-14 23:22:42 +08:00
thzxx c0d85eeaab docs: PLAN 追加 v0.8.0 实施进度日志（附录 F）—— 已完成 8 项提交 / 待完成清单 / 实施中的额外发现 2026-09-14 22:04:07 +08:00
thzxx c8b59bd16f docs: v0.7.4 全量深度审计 + v0.8.0 根治性迭代方案 
- 全源码逐行通读（src 16079 行 / tests 20223 行 / 文档 4349 行），7 个子系统并行深度审计
- PLAN-v0.7.5.md：8 大根因分析 + 3 条并行工作流 + 55 项缺陷总账 + 6 道硬门禁
- AUDIT-aria-lsm / AUDIT-query-layer / AUDIT-storage-engines：逐条 file:line 证据
- 全部关键结论经可执行探针实测复现（探针已删除，仓库无残留）
 2026-09-14 20:37:44 +08:00