3 Commits

Include renames

Author	SHA1	Message	Date
xuyueandClaude Opus 5	ed56a209ea	chore(格式): Prettier 统一到全仓，后端和契约一次性格式化 ... 原来只有 `apps/web` 在 Prettier 下（配置在 `apps/web/.prettierrc.toml`、脚本在 web 的 package.json），后端和契约从来没格式化过 —— 手写在 100 列上下，`db/schema.ts` 还是 drizzle-kit pull 留下的 tab 缩进。两套口径分叉久了，跨端改一处就得记着「这边 什么风格」。 - 配置搬到根目录 `.prettierrc.toml`，内容不变（`semi=false`，其余全默认， printWidth 80 —— 和前端已有的格式一致，不另立一套宽度）； - 脚本统一成根目录 `bun run fmt`，覆盖 `apps/*/src`、`apps/web/tests` 和两个构建 配置；web 自己那份 `fmt` 和重复的 prettier 依赖删掉； - `.prettierignore` 挡掉两类不该碰的：drizzle-kit 生成的 `src/db/meta/` 结构快照 （它是 db:generate 的比对输入，只该由 drizzle-kit 写）、unplugin 每次 dev 都会 重写的 `auto-imports.d.ts` / `components.d.ts`； - 全量跑了一遍。纯格式，无行为改动：api typecheck / check:routes / check:ast、 前端 type-check 全过，起 api 打了接口确认正常。前端这 39 个文件的小改动是 prettier 版本漂移（类型断言的换行口径变了），不是新配置带来的。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-16 08:27:34 -06:00
xuyueandClaude Opus 5	586c88f629	build(数据库): 改用 drizzle migration，加提交列表索引、清掉 Django 残留 ... 一条线上的三件事：让 drizzle 的迁移机制真正可用 → 用它加索引 → 用它清掉 不再需要的 Django 表，最后接进部署和 CI。 ## 1. 让 drizzle-kit generate 可用 原本以为不能用：只加一个索引，generate 却吐出一堆噪音，其中 5 条 `DROP SEQUENCE auth_*/django_*` 打到生产库上会直接搞坏旧后端。 逐个查下来全是 `pull` 出的基线自己不能 round-trip，都是可修的： - **快照里的 Django 序列**：tablesFilter 只过滤表、不过滤它们的序列。 已从 0000_snapshot.json 清掉。 - **bigint 上限精度**：pull 生成的 `maxValue: 9223372036854775807` 是 JS number 字面量，round-trip 成 ...776000，每次 generate 都多出 10 条 ALTER COLUMN。改成字符串。 - **表达式索引的 opclass**：problem_tag_name_ci_unique 在快照里带 opclass，drizzle 自己序列化不出来，导致每次 drop + recreate。已去掉。 改完 `generate` 是干净的 no-op。 两个改不掉、只能绕的写进了 CLAUDE.md：索引 `.desc()` 生成 SQL 时会被丢 （单列索引不写方向即可，Postgres 用 Index Scan Backward 服务 ORDER BY DESC，实测同样 0.08ms）；migrator 把所有语句包一个事务， CREATE INDEX CONCURRENTLY 跑不了。 最容易吃亏的是 drizzle 没有 --fake-initial：对已有数据的库直接 migrate 会从 0000 跑起、撞表回滚，**而且 exit 1 但一个错误都不打印**。 ## 2. 0001 提交列表索引 `WHERE contest_id IS NULL ORDER BY create_time DESC LIMIT n` 用不上现有的 contest_create_time_idx (contest_id, create_time DESC) —— Postgres 不把 `IS NULL` 当成能吃掉首列、从而继承第二列有序性的等值条件。把 enable_seqscan / enable_bitmapscan 全关掉逼它用也不肯，宁可走单列 contest_id 索引再全量排序。于是每翻一页都 Parallel Seq Scan 扫完整张表。 换成部分索引后谓词由索引自己保证，索引序就是查询要的排序序。生产快照 （12.3 万条提交）实测首页取 10 行：61.8ms / 读 18936 blocks → 0.22ms / 读 34 blocks。端到端 94ms → 6ms。 真正要命的不是单次 61ms，是每个请求都要把 169MB 的表刷一遍 shared_buffers —— 一节课几十个学生同时开提交列表，磁盘和缓存直接被打穿。 ## 3. 0002 删掉 Django 残留 确认旧 Django 后端不再使用、也不再作为回滚路径。删前核实过：没有任何 OJ2 保留的表引用这 7 张，3 条外键全在它们内部（所以不用 CASCADE，真有 漏网的会报错而不是被悄悄级联掉）；5 个序列都由各自的表 owned，随 DROP TABLE 一并消失；数据全是 Django 自身元数据。tablesFilter 随之移除。 **回滚路径就此作废** —— CLAUDE.md 开头和 runbook 的「回滚保证」「七、回滚」 都改了。这条迁移已在本机 dev 库和生产快照副本上跑通，**生产库尚未执行**。 ## 4. migrate 接进部署与 CI deploy.sh 在构建之后、起栈之前跑 `oj2-api migrate`，失败就中止部署（旧 容器原样还在跑）。CI 走的也是 deploy.sh，所以不用给 GitHub 配数据库凭据， 也不用把生产库对外开放。 迁移文件**不内嵌进二进制**，随镜像装在 /usr/local/share/oj2/migrations。 这样 drizzle 的 migrate() 能原样用 —— 靠 _journal.json 自动发现，新增迁移 不用改任何代码，和 Django 扫 migrations/ 是一回事。内嵌就得为每条迁移 手写一行 import，那是迟早会漏的账。（CLAUDE.md 里「单二进制不能读文件」 那条讲的是 node_modules 和 import.meta.dir 推路径，按显式绝对路径读一个 数据目录不在此列。） 三道闸门，都是写完测出来才补上的： - **破坏性迁移拦截**：DROP TABLE / DROP COLUMN / DROP SCHEMA / ALTER COLUMN ... TYPE / TRUNCATE 命中就退出 4，需要 `OJ2_ALLOW_DESTRUCTIVE=1` 显式放行。DROP INDEX / DROP CONSTRAINT 不算， 拦了只会让人习惯性带上放行开关。扫描前先剥注释，避免误报。 - **基线缺失**：退出 3 并直接打印该敲的 SQL。注意判的是 `max(created_at) < 0` 而不是「表不存在」—— 表存在而为空（上次迁移失败 留下的）同样是没基线。 - **迁移目录读不到**：这是最可能犯的错（Dockerfile 漏拷），原本是 drizzle 的堆栈，现在直接说该检查哪一行。 另外发现 0000_crazy_gateway.sql 是 pull 的产物，**整份被 /* */ 包着， 可执行语句 0 条**，所以这个库根本不能靠迁移自举建表。原先写的「空库就从 0000 建」跑起来会炸在一个和真实原因毫不相干的 unterminated /* comment 上。 现在如实说明：结构只能来自 docs/specs/schema.sql 或生产 dump。 验证：镜像内编译（ARTIFACTS=build）出的真实镜像跑完五种场景 —— 拦截、 放行、幂等、无基线、漏拷目录，全部符合预期；dev 形态同样五种场景全过。 tsc / 路由遮蔽 / deploy.sh 语法 / generate no-op 都通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 07:56:30 -06:00
xuyueandClaude Opus 5	ce21a2bb8f	feat(阶段5): 让 bun build --compile 的产物真正自足 ... 编译产物拿到没有 node_modules 的目录里跑，原来是一路崩的 —— 而且**在仓库 目录里跑时全都正常**，因为它顺着 cwd 找到了 node_modules，假装没事。 这类问题只会在服务器上第一次启动时暴露。逐个堵掉： - `import.meta.dir` 在二进制里恒为 `/$bunfs/root`，往上三级就是文件系统根： `data/test_case` 悄悄变成 `/data/test_case`，`.env` 去读 `/.env`。 新增 runtime.ts 显式分叉：编译后按 cwd，开发时按仓库根（后者不能改， compose 挂给判题沙箱的是仓库根的 data/test_case）。 - sql.js / tree-sitter 的 wasm、jieba 的 .node 和 4.8MB 词典， 原来都靠运行时 require.resolve / Bun.resolveSync / __dirname 去 node_modules 里找。 全部改成 `with { type: "file" }` 内嵌成资源。jieba 尤其绕：它的 index.js 运行时探测平台再 require 子包，dict.js 用 __dirname 读 dict.txt，两条都 依赖磁盘布局，所以单独包了 vendor/jieba.ts 直接 require 内嵌的 .node。 - SQL 判题要 spawn 一个能被 SIGKILL 的子进程，原来 spawn 的是 child.ts 的路径， 编译后那个文件不存在。改成二进制自己按 argv 分发：新增 main.ts 作为唯一入口， serve / worker / sql-child 三个子命令，镜像里只需要一份运行时。 ## 顺带修掉一个能拖垮生产的坑 「spawn 自己」意味着只要 argv 分发这一环出问题（子命令改名没同步、compose 里 command 写错、拿别的入口编了二进制），「起自己」就变成「把整个程序再跑一遍」， 而那一遍又会 spawn 一个自己 —— 指数增长。 这不是假想：开发时用一个没有分发器的临时入口编了个二进制，一跑就递归 fork 105MB 的进程，几秒触发 global OOM，内核把开发机的终端杀了 （`selftest invoked oom-killer ... Killed process ... Alacritty`）。 同样的错误发生在服务器上就是判题机连同数据库一起拖死。 加了递归闸：父进程 spawn 时打 OJ2_SQL_CHILD 标记，带标记的进程一律拒绝再 spawn， 最多一层就停在一条明确的 SYSTEM_ERROR 上。 ## 验证 产物拷进只有它自己一个文件的目录，2G 内存上限下跑，7 项全过： jieba 分词（自定义词「循环结构」「死循环」命中）、tree-sitter Python3/C 各两条 （含一条**预期失败**的规则做对照，否则「语言没加载成功」和「规则通过」返回值 一模一样，分不出来）、SQL 判题 AC、SQL 只读防护仍拦住 PRAGMA。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 23:13:57 -06:00