|
|
fafeebd281
|
feat(运维): 加 oj2-api recount，把反范式计数列对回 submission 表
Deploy / deploy (push) Has been cancelled
problem.submission_number / accepted_number / statistic_info 和 user_profile 的
submission_number / accepted_number / acm_problems_status 由 judge/run.ts 的
persistResult 在判题时手工加减，上线至今没人事后核对过。
已知的漂移来源是重判：routes/submission.ts 的 rejudge 把 result 打回 PENDING
就重新入队，不回退任何计数，persistResult 随后再加一次。实测重判一条提交，
problem 的 submission_number、statistic_info 和 user_profile 的 submission_number
全部虚增，而提交一条没多。
默认只读预演，--apply 才写，落库后用同一份 computePlan 复核，还剩差异就非零退出。
口径逐条照抄 persistResult：题目侧连比赛提交一起算、用户侧只算非比赛；
accepted_number 是去重到题的首次通过；acm_problems_status 通过过就恒为 ACCEPTED，
没通过过取最后一次结果。acm_problems_status 里 problems / contest_problems 之外
的顶层键原样保留 —— 来历不明的数据不该被重算顺手抹掉。
不管的：acm_contest_rank（罚时与每题尝试次数口径复杂，单独一件事）、
achievement.unlock_count（0010 之后随成就级联，漂不了）、题单进度与奖章
（走 backfill-problemsets）。
--apply 要挑没人做题的时候跑：差异在事务外算、写的是绝对值，算完到写完之间判完
的那一笔加法会被覆盖；复核会把它报成「仍有 N 处差异」并以 1 退出，不会静默。
验证：dev 库先备份计数列，测完原样还原（差异数 0）。验过收敛（--apply 后再跑报
一致）、真实重判造成的漂移精确报出 3 处且无误报、人为删掉某学生已 AC 的格子能按
「曾经 AC → ACCEPTED」恢复、注入的未知顶层键完好保留。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AeJoYc2t2d7cThVqMBYrBF
|
2026-09-02 22:58:01 -06:00 |
|
|
|
74b97c610f
|
fix(题单): 「选做」终于作数了，分母只算必做题
isRequired 一直只是卡片上的一行字：卡片写着「（选做）」，进度分母和 all_problems
奖章却照样要求做完。结果是学生按提示跳过选做题，进度条卡在 100% 以下、全通奖章也
拿不到 —— 快照里 22 个人做完了全部必做题却显示未完成（题单 5 三人、6 十人、8 两人、
11 七人）。旧栈的 update_progress 同样不区分，是一路继承下来的。
改成：分母只算必做题，选做题做了仍然计分（totalScore 把它算进去），只是不卡完成。
一道必做都没标的题单退回「全部都算必做」—— 那种题单多半是没用这个字段，而不是真的
整单选做，不兜住的话它永远完不成。
## problem_count 奖章不能跟着改
老师当初是按题单的**总题数**设阈值的：题单 5 的「一职欧拉」要 8 题，而它的必做只有
7 道。要是 problem_count 也改用只数必做的 completedProblemsCount，这枚奖章一夜之间
不可得，76 个已经拿到的人会被 recalculateBadge 收回。所以它数的是「做出的题目总数
（含选做）」，从 progress_detail 的键数来。score 类同理不受影响。
预演证实了这道闸门有效：22 人拿到完成状态，奖章补发 56 条、**收回 0 条**。
## 顺带：第三份手抄的达标逻辑
PUT /problem-set-progress 里还藏着一份 inline 的奖章判定，和 services 里那份、
补发脚本里那份是三份各写各的 —— 这次改 problem_count 的语义，漏掉任何一份都会让
学生提交时发的奖章和后台重算的结果对不上。三处统一到 eligibleForBadge。
## 工具改名并扩到进度
backfill-badges → backfill-problemsets。语义变更之后，已有的进度行要跑一遍才会按新
规则重算，否则那 22 个人得等到老师下次动题单才生效。两笔账本来也是同一笔：进度一变，
奖章达标面就跟着变，所以落库走 resyncProgress（它重算进度后会顺手重算该题单全部奖章），
预演里的奖章差异也是照着订正后的进度算的，保证预演和 --apply 的结果一致。
在生产快照上实跑：
合计：进度 494 条要重算（完成 +22 / -0），奖章补发 56 条、收回 0 条
已订正 10 个题单 → 复核通过：题单数据与规则一致
user_badge 1180 → 1236，已完成 621 → 643
「未完成但有完成时间」仍是 4 条（d7a6414 那条语义保住了）
重复跑幂等：进度 0 条、奖章 0 条
抽查题单 6（9 必做 + 1 选做）：只做必做的显示 9/9 100% 已完成、80 分；连选做一起做的
同样 9/9 已完成，但 90 分。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
|
2026-08-31 08:55:36 -06:00 |
|
|
|
05cf8011e3
|
fix(题单): 奖章补发改成二进制子命令，独立脚本在生产跑不了
Deploy / deploy (push) Has been cancelled
上一版把补发写成 `bun src/scripts/backfill-problemset-badges.ts`，那在生产上根本执行
不了 —— api 镜像是 debian-slim + 一个编译好的 oj2-api，既没有 bun 也没有源码。
改成 main.ts 的子命令，跑法对齐 migrate（deploy.sh:197 就是这个形态）：
docker compose -f docker/compose.debian.yml run --rm oj-api oj2-api backfill-badges
docker compose -f docker/compose.debian.yml run --rm oj-api oj2-api backfill-badges --apply
脚本本身从「导入即执行」改成导出一个返回退出码的函数，main.ts 负责解析参数和 exit。
package.json 的 backfill:badges 也指向同一入口，本机和生产走的是同一条代码路径。
用编译出来的二进制在 /tmp 下实跑过全部四条路径（预演 / --apply 后自动复核 / 重复跑
幂等 / 误发时拒绝执行并退 1，加 --allow-revoke 才收回），确认动态 import 的模块进了
bundle、不依赖源码树。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
|
2026-08-31 08:26:27 -06:00 |
|
|
|
586c88f629
|
build(数据库): 改用 drizzle migration，加提交列表索引、清掉 Django 残留
Deploy / deploy (push) Has been cancelled
一条线上的三件事：让 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 |
|
|
|
f6bc42f534
|
docs: 给 OJ2 补一份自己的 CLAUDE.md；Dockerfile 拷上 bunfig.toml
## bunfig.toml 没拷进容器，才是那批「本地能过、容器过不了」的根因
bunfig.toml 里设了 `linker = "hoisted"`，但 Dockerfile 只拷了 package.json 和
bun.lock，于是容器里用的是默认的 isolated 布局（包都在 node_modules/.bun/ 下），
本地靠"提升"才解析得到的包在容器里一律 Could not resolve —— 而本地构建始终是好的，
只有镜像构建才炸。之前是一个一个补直接依赖补过去的（那是对的、该保留），
这里让两边布局一致，是第二道保险。
带上之后装 622 个包（isolated 是 1238），镜像重建通过，二进制在容器里
serve + healthcheck 正常。
顺手补了 main.ts 帮助文本里漏掉的 healthcheck 子命令（compose 里把 command
写错时，看到的就是这行）。
## OJ2/CLAUDE.md
OJ2 是独立仓库，之前没有自己的项目指引。写了一份，重点是几条「不知道就会踩」的：
- **本机 Docker 可用**，整套依赖和上线演练都能在本机跑 —— 别沿用上一代
"本机跑不起来后端"的旧假设
- 单二进制不能依赖 node_modules，`.node` 资源导入 dev 和编译两种形态行为不同，
**改完两种形态都要跑**
- SQL 判题 spawn 的是二进制自己，入口必须有 argv 分发，那道递归闸不能删
- 判题状态码三处同步、raw_password 要保留、比赛只有 ACM、前端要兼容老 Chrome
- 不写迁移：新旧后端跑同一套表结构，这是回滚能成立的前提
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-08 03:37:45 -06:00 |
|
|
|
ea521e7b0a
|
feat(阶段5): 镜像、三套 compose，前端切回 /api 与 /ws
## 镜像
一个 Dockerfile 两个 target：api（单二进制）和 web（Caddy + 前端产物）。
旧后端是一个容器里用 supervisord 跑 caddy+gunicorn+dramatiq，这里拆成
oj-web / oj-api / oj-worker 三个容器 —— Docker 本身就是进程管理器，
拆开之后 worker 挂了能单独重启、日志也分得开，少一层 supervisord 要维护。
同一个镜像换个子命令就是 worker，镜像里只有一份运行时。
新增 healthcheck 子命令：运行镜像是 debian-slim，没有 curl/wget，
让二进制自己打 /health（只打 /health 不碰库 —— 库挂了该由库的 healthcheck 报，
不该让 api 跟着被判不健康然后被重启）。
**数据目录照抄旧后端**（test_case、public/upload、public/avatar）。
不是审美问题：切换那天不用搬动任何文件，回滚时旧后端立刻能找到自己的数据。
少一次几十 GB 的 mv，就少一个在停机窗口里出错的机会。
构建路上踩到三个坑，都是「本地能过、容器里过不了」那一类：
- 构建上下文吸进了 data/，judge_server/run 是判题沙箱用别的 uid 建的，
docker 连 stat 都做不了，构建直接失败 → 补 .dockerignore
- mermaid@9.4.3（机房老 Chrome 的 legacy 依赖，不能砍）从容器里连
registry.npmjs.com 稳定失败，主机上没问题 → 换 npmmirror，并重试两次
- 容器里 bun 用 isolated 布局，本地是扁平的。靠「提升」才能解析到的包
在容器里一律解析不到：@node-rs/jieba-linux-x64-gnu（编译要 import 它的 .node）、
以及前端的 @codemirror/{language,state,view} 和 @lezer/highlight。
这些本来就是代码直接 import 的，补成直接依赖。顺手写了个脚本扫全仓，
确认只有这 4 个。
## 前端切回 /api、/ws
迁移期用 /api2、/ws2 指新后端，/api、/ws 还指着 Django。端点已全部搬完，
临时前缀去掉。改动只有三处（api2.ts 的 baseURL、websocket.ts 的两个 URL），
`api2` 那些 import 是模块名不是路径，不动。vite 代理同步收敛成三条。
## compose
- debian：全套（含 postgres，对外开 5445 给机房连）
- school：**没有 postgres**，连服务器的库；本地 Redis + 本地判题沙箱
- 两边共用一个库但各有各的队列和 WS 推送，和旧后端的 Dramatiq/Channels 拓扑一致
密钥一律走 env 且带 `:?`，没设置就直接报错退出，不静默用弱默认值。
COOKIE_SECURE 在机房必须是 false（http 直连 IP，带 Secure 的 Cookie 发不回来，
表现是「登录成功但立刻又变未登录」）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 23:41:20 -06:00 |
|
|
|
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 |
|
