OJ2/docs/specs at c59ecd6dbbe185b3a7a4e763b606f683165a1120 - OJ2

xuyue/OJ2

Files

yuetsh c59ecd6dbb fix(SQL 沙箱 Minor): 让题目的 memoryLimit 对学生真正生效

## M-1

题目写 64MB 也没意义 —— 唯一的硬顶是子进程那个固定 512MB 的 ulimit -d，
学生实际能吃到 8 倍。旧实现是 setlimit(SQLITE_LIMIT_LENGTH, memoryLimit)
把单值长度贴着题目内存限，但 sql.js 的 wasm 没导出 sqlite3_limit（已核对导出表），
复刻不了。

改成引擎侧按字节记账（ByteBudget）：取行时累加，单值超限或结果集累计超限都按 MLE 拒。
max_page_count 管的是库文件页数，管不住「一个 SELECT 拼出一个巨大的值」，所以两者
不重复。查询题和增删改题（dumpTables）两条路都记账，受信脚本不记。

实测 6 条，关键是**同一句 SQL 在 4MB 的题上被拦、在 64MB 的题上放行**，
证明限制跟着题目走而不是一刀切。

第一版测试用的是 100MB 的值，结论是错的：wasm 堆触顶时的兜底和我的记账器报的是
同一句「单个数据值超出内存限制」，大值根本分不清是谁拦的。换成 8MB 才测得准。
这个教训写进注释了。

M-1 的第二半（max_page_count 学生可自行调大）在 I-1 拦 PRAGMA 时已一并修掉。

## M-3

阶段 5 的分阶段兜底超时顺带解决：出题人预览死循环从 25s 降到 13005ms 实测。

## M-2 不修

「强制两个测试点期望结果不同」会把合法出题也挡掉（刻意用两组数据验证同一边界、
结果恰好相同），代价是老师被一条看不懂的错误拦住。评审也确认与旧实现一致、非回归。
更合适的是提示而非拒绝，但要动契约和后台前端。理由写进评审文档，免得下次又当新发现。

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

2026-08-08 02:27:35 -06:00

2026-08-06-bun-backend-rewrite-design.md

docs: 更正本机开发环境约束 —— Docker 可用

2026-08-06 20:30:17 -06:00

endpoint-inventory.md

docs(阶段0): 端点清单人工裁决完成

2026-08-06 20:22:34 -06:00

phase3-coverage.md

docs(阶段5): 用生产快照跑完整切换演练

2026-08-08 02:13:59 -06:00

phase3-fix-list.md

docs(阶段3): 记录 7 条 Minor 的逐条结论