xuyue/OJ2
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
661 Commits 1 Branch 0 Tags
6176b80ad947bff6cb317f6381076db598a28e54
Commit Graph
28 Commits
Author SHA1 Message Date
xuyueandClaude Opus 5.5 37e971b6b4 refactor(判题机): 换成 go-judge，空闲内存从几百 MB 降到 16 MB 
原来的 JudgeServer 按核数起 gunicorn worker、每份提交再按核数开进程池，空闲内存跟着核数走
（2 核 52MB、16 核 305MB）。换成 go-judge 后空闲 16MB，同一批提交判题中 80–100MB（原来约 370MB）。

go-judge 只管在沙箱里跑命令，编译、逐点运行、比对输出、定状态码搬到 judge/sandbox.ts，
口径逐条照搬 JudgeServer，出参形状不变。拿生产库真实提交新旧逐点对比：C 2000 份 1989 一致、
C++ 891 份 890 一致、Python 2000 份全一致；不一致的是 system("pause")（现在不再判运行时错误）、
未定义行为、endl 死循环打印（运行时错误变运行超时），见 docker/judge/README.md。

- 判题容器改成 privileged（go-judge 要自己建 cgroup），镜像 oj2-judge-3
- 心跳改由 worker 每 5 秒问判题机 /version 代记，删掉 /api/judge-server/heartbeat
- 前端统一用 stripJudgePath 去掉判题机工作目录（新的 /w/ 和旧的 /judger/run/）
- 提交前编译检查只编译不运行

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-26 15:03:57 +08:00
xuyueandClaude Opus 5.5 195069450f style(格式化): 改成单引号、一行最长 160，全仓重新格式化
Deploy / deploy (push) Canceled after 0s
Details 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-26 13:52:24 +08:00
xuyueandClaude Opus 5.5 0faf78ad8f feat(挑战): 做对之后可以加一条写法上的限制再做一遍，判题时记下谁做到了 
借小丑牌的赌注档：同一道题加一条限制（「整首歌只用 1 次 print」）再做一遍，
给课上做得快的学生找事做（做完一节课的题，中位要空等 13 分钟）。
判定沿用 AST 规则，挑战配在 problem.challenges，做到的记在 challenge_success；
做对的提交顺手判一遍，挑战没做到也照样算做对。没过的规则带上是第几行。
0039 灌进第一批 56 道常用题的 73 条挑战，api 起来后拿历史上做对的代码补一遍谁已经做到了。
出题页能配挑战、从做对的代码里找候选；课堂看板的格子带上挑战状态。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-26 08:52:50 +08:00
xuyueandClaude Opus 5.5 307b0725d0 perf(判题): 判题机上同时跑的程序从最多 8 个压到 4 个，挤的时候不再把不超时的判成超时 
原来四道闸各管各的（worker 判题 2、api 试运行 2、提交前编译检查 2、worker 里流程图
评分的试运行又 2），api 和 worker 两个进程互相看不见，峰值 8 个程序压在服务器两个核上；
判题机按墙钟判超时，挤到一定程度会冤枉学生。

judge/slots.ts 在 Redis 里按池数名额（每个站点各数各的）：
- 后台池（正式判题、诊断重跑、流程图评分）上限 JUDGE_CONCURRENCY
- 交互池（运行例子、自己输入、生成测试点、编译检查）上限 TRIAL_CONCURRENCY
两池不互相借，正式判题排再长也挤不掉学生的「运行例子」。名额是带到期时间的租约，
进程被杀了到期自动作废；Redis 出错直接放行。正式判题的超时从拿到名额才开始算。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-16 14:47:24 +08:00
xuyueandClaude Opus 5.5 55038cc78b fix(判题): 判题机卡住不再让全班一直「等待评分」，重判和同时交对也不再把做对题数算多
Deploy / deploy (push) Canceled after 0s
Details 
- 正式判题、样例重跑、运行时错误诊断都加了超时（默认 120 秒，时限放宽的题按比例放宽），
  超时记系统错误、提示是中文；回包和试运行一样边读边数，超过 16MB 就掐断，
  免得一个疯狂打印的错误程序把 worker 撑爆
- 做对题数、中等、困难、一次就对改成在锁里按定义现数：原来逐次 +1，两条挨着判完或重判
  一条做对的提交都会多加，库里 372 人多了 1–4 道。0035 把存量一次订正
- 重判不再给提交次数、凌晨/早起计数 +1，编译错误按前后差值改；「错了几次才对」只数这条之前的
- 已拿到的成就数只 jsonb_set 那一个键，不再整块写回冲掉并发判题刚写的指标

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-16 14:15:08 +08:00
xuyueandClaude Opus 5.5 cff989bf19 perf(提交): 格式化前送判题机编的那一下改成排队，一个班同时交也不会把判题机挤到人人超时
Deploy / deploy (push) Canceled after 0s
Details 
格式化前的编译检查不走判题队列，原来来多少份就同时往判题机上压多少份。服务器只有两核，
按两核实测 40 份 C++ 同时压上去，每份都撞 8 秒超时，正式判题也跟着变慢。现在同时最多
2 份，其余排队，8 秒是连排队带编译的总预算，排不上就当编得过、照常格式化。

同样 40 份，现在 5.2 秒全部编完、判断全对；压到 80 份时有 24 份等满 8 秒放弃。上一个提交
之后，编得过的代码只有 1～2% 还会走到这一步，平时基本排不起队。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-14 12:24:07 +08:00
xuyueandClaude Opus 5.5 646c57c748 refactor(题单): 难度、状态、分数、提示、总分、百分比和 problemset_submission 表不再读写，先补默认值、下一步再删
Deploy / deploy (push) Canceled after 0s
Details 
机房和服务器共用一个库、不一定同时升级，所以分两步退役：0027 只给还非空的几列补默认值，
新代码插行不用再填、没升级的那边照旧能跑；两个站点都换上新代码后，再单独一条迁移删列删表
（要手工放行破坏性迁移，语句写在 0027 的注释里）。

进度算法随之去掉分数和百分比，判题记进度不再往 problemset_submission 写一行（从来没人读）。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-09 22:08:15 +08:00
xuyueandClaude Opus 5.5 c2ef55b10b fix(提交): C 代码编译不过时，提交前的自动格式化把出错的几行并成一行，学生认不出自己的代码
Deploy / deploy (push) Canceled after 0s
Details 
clang-format 不认中文分号、缺了分号的语句，会把它和下一行并起来（int n； 和 scanf 成了
一行），报错的行号也对不上学生记得的位置。现在 C / C++ 格式化之前先套上题目模板、在
判题机上编一次，编不过就原样返回、不格式化，代码照常提交、照常判成编译错误。

api 容器里没有 gcc，判题机的编译器和参数本来就是判的标准，所以借它编。这一下不进判题
队列、不建提交记录；判题机连不上时照旧格式化。代价是每次交 C 多一次编译，零点几秒。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 11:29:37 +08:00
xuyueandClaude Opus 5.5 79ca8ac3bd feat(运维): 新增 oj2-api rediagnose，旧提交的运行时错误说明也能用上新规则 
诊断是判题时写进库的，规则改了旧提交不跟着变。这个子命令把库里的诊断按现在的规则重做：
Python 只重做已经有诊断的（重跑第一个失败测试点拿回溯，所以要在线上 oj-api 容器里跑），
C / C++ 用 info 里存着的信号和退出码直接补上（原来一条都没有）。比赛提交不诊断，
重跑不出来的保留原样，只写 runtime_error 这一个键。默认只读预演，--apply 才写。

本机验过：dev 与编译两种形态都跑通，--apply 之后再跑是 0 条变化。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 10:51:54 +08:00
xuyueandClaude Opus 5.5 e118d80057 fix(判题): 题目缺测试数据时学生看到「编译错误」和一句英文「Test case not found」，以为是自己写错了
Deploy / deploy (push) Canceled after 0s
Details 
判题机的 err 只有 CompileError 是学生的错，别的（JudgeClientError 之类）原来也一律
记成编译错误，全库 337 条，最近一条在 2026-09。改记系统错误，学生那边说「判题出了
问题，不是你的代码写错了，告诉老师」，不再贴英文原文。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 10:44:09 +08:00
xuyueandClaude Opus 5.5 96ce9725b2 fix(语法错误): 有模板的题报错行号多 1；else 后面写了条件被说成「少了冒号」，a+b=c 被说成「判断相等要用 ==」 
全库 9182 条 Python 编译错误逐条过了一遍翻译表，1014 条的说明变了：

- 行号：判题跑的是「模板 + 代码」，运行时错误扣了模板行数、编译错误没扣，
  「第 N 行」和标红都落在下一行（691 条）。提交和运行例子两条路都扣上，
  gcc 的 main.c:N: 和代码摘录左边的行号一起扣。报错前先打了一条警告时
  File 那行是缩进的，行号原来解析不出来。
- 同一句报错要看出错那一行才分得开：expected ':' 九成是 else a<60:（行尾有冒号），
  「Maybe you meant '=='」只有 if / while 行才是真想判相等，a+b=c、a=96,b=92、
  print(1+1=2) 各有各的说法。
- 选了 Python 却交了 C 代码（294 条），直接说换语言。只凭 printf 不算：
  Python 里 print 手误成 printf 的不少。
- 单独说清楚的：elif: 没写条件、esle / else if、=< 写反、条件之间用逗号、
  漏了 +、√ ² ≤ ≥、顿号、全角 ＃、emoji（正则少了 u 标志）。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 10:44:09 +08:00
xuyueandClaude Opus 5.5 26c8d65e89 fix(判题/统计): 老师重判一次题目提交数就多一；统计选 231 班会把 2311、2312 班也算进来 
- 重判带上原来的结果，落库只做差量：提交数不变、旧结果那一格减一新结果加一，
  通过数按新旧结果调整（原来重判当新提交记账，连点三次就多三）。重判时一起清掉 info，
  判题中那几秒不再按旧结果显示「通过 2/3」
- 三个统计接口加 className，按 class_name 精确匹配（原来拼 ks231 做包含匹配）
- 流程图统计查几道题时要每道都拿到 A/S 才算完成；「每人最好的一次」截断时有标记，
  题号上限 20 道和代码统计一致；流程图列表支持按整名匹配用户
- 删掉统计弹框走后没人用的展开行明细接口，以及每次都白算的「语法未过题数」「最近一次错在哪」

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-29 18:52:58 +08:00
xuyueandClaude Opus 5.5 eb32676de4 feat(题目): 「运行例子」「自己输入」改用和提交同一台判题机——例子上跑出什么样，提交在这几个例子上就是什么样
Deploy / deploy (push) Canceled after 0s
Details 
原来试运行走另一台 Judge0：C 是 GCC 9、编译参数也不一样，Python 的语法错误回来的是运行错误，
没有题目的时间内存限制和代码模板，例子上的结果常和提交对不上。现在走本站判题机
（POST /trial-runs），同一套编译命令、这道题的限制和模板，对不对也由判题机比。

- 不落库、不算提交、不进判题队列：api 进程里自己排队，全站同时 TRIAL_CONCURRENCY 批
  （服务器 2、机房 4），每人最多两批，排满或等超过 30 秒就请学生过一会儿再点
- 死循环不停打印时判题机回包会很大，超过 16MB 就掐断，告诉学生输出太多、停不下来
- Python 语法错误用和提交一样的说明：第几行、中文标点标红、一键换成英文
- 运行时错误和提交用同一个解析，说清楚第几行、为什么（下标越界、int() 转换失败、段错误……）；
  比赛里照旧只给按结果码的那一句
- 语法没过、服务没跑成时，标题不再说「N 个例子没对上」
- 后台「生成测试点」一并迁过来，编译警告不会再写进 .out；Judge0 的地址和调用全部删掉

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-29 08:09:44 +08:00
xuyueandClaude Opus 5.5 3fe3caa944 feat(流程图): 流程图画到 A / S 算这道题做完——题单进度、课堂条都认；加入题单之前画的图先藏起来
Deploy / deploy (push) Canceled after 0s
Details 
- 流程图评到 A 或 S，记进所有已加入、且包含这道题的题单（和判题那一路同一个口径，不看从哪个
  入口交的），徽章和题单类成就照样推送。原来题单进度只在判代码时记，流程图作业在题单里永远是
  「没做」。流程图提交的 id 进不了 problemset_submission（外键指向代码提交表），所以只写
  progress_detail —— 解锁旧提交的那道闸看的也是它
- 课堂条（/me/class-activity）的 myStatus：流程图 A / S 也算 accepted，评完的非 A/S 算 tried
- 题单防抄闸门补到流程图上：加入题单之前画的图，对本人藏起来（列表 showLink、详情 404、
  current / history 不数它），规则和代码提交同一份（problemSetJoinTimes 挪进 services/problemset）。
  原来加入之前画到 A 的那张图点一下就能载回画布、交上去就是 A
- 新增 GET /problems/:id/flowchart/scores：一次给出自己评完的每一次的分数和等级，外加被藏起来
  的次数（原来 history 一次只给一条，看分数走势得一页一页翻）
- 「A/S 算过关」和按分数定等级收进 flowchart/grade.ts；判题那边的记账 + 通知抽成
  recordSolvedAndNotify，两条路共用

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-28 17:56:35 +08:00
xuyueandClaude Opus 5.5 7e964fdbdd feat(题目): 答案错误时拿公开样例重跑，并排显示正确输出和你的输出，按差异类型给中文提示
Deploy / deploy (push) Canceled after 0s
Details 
原来答案错误只有四个字。6901 条历史答案错误在公开样例上重跑过：73% 在样例上就错了，
其中约三分之一只差格式（没输出、input() 提示文字、空格换行、中英文标点、小数位数）。

- judge/run.ts 的 checkSamples：判出答案错误后以内联测试点重跑题目样例（output: true），
  记下第一个没过的样例和学生在它上面的输出，写进 statistic_info.sample_check；
  样例全过则只记 passed。全是公开信息，不碰隐藏测试点；比赛不跑（有期末考试）
- 前端按差异归类（数字先于「多了内容」判，免得 007 被当成多打了文字），
  并排显示输入 / 正确输出 / 你的输出，标出第一处不同的行；只差空白时把空格、换行画出来，
  末尾空白不画（判题本来就忽略）
- 提示给具体值（「正确输出是 84.10，你输出的是 84.1」），input("…") 单独提示

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-27 22:14:24 +08:00
xuyueandClaude Opus 5.5 db70ab62e8 feat(题目): 运行时错误告诉学生第几行、为什么出错（Python 看回溯，C 看信号），不泄露测试数据 
原来学生只看到「运行时错误」四个字：主判题 output: false，Python 回溯没回来；
C 的信号值在 info 里，而 info 只给管理员。

- Python 判出 RE 时，拿第一个失败测试点单独重跑一次（内联测试点 + output: true），
  从回溯取行号（扣掉模板前置行）、异常类型和按句式归的类别。主判题仍不开 output，
  免得每个点最多 16MB 的输出回到 worker
- C / C++ 取失败点的信号和退出码（段错误提示 scanf 漏 &、return 非 0 等）
- 写进 statistic_info.runtime_error；不存异常原文（里面常带测试点输入），名字只在
  出现在学生代码里时才存——raise Exception(input()) 实测只落下类型
- 前端按类型翻成中文、摆出出错那行并在编辑器标红；比赛提交不诊断（ACM 只报对错）
- 没有诊断的 RE 不再说「代码格式写错了」

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-27 22:01:30 +08:00
xuyue d25b5dbe6d update
Deploy / deploy (push) Canceled after 0s
Details
2026-09-27 19:36:28 +08:00
xuyueandClaude Opus 5.5 5ae830a7f9 refactor: 一批名不副实的命名改掉（只动一端，不碰契约） 
后端：
- getUserByToken → authenticateToken：它会删会话、续 TTL、记在线，不是纯读
- todayStart → dayStart(instant)：本来就接受任意时刻，不只是「今天」
- objectValue → asRecord，删掉 4 份一模一样的私有拷贝和 `as toObject` 别名
- 报错文案 "does not exists" / "Already be a public problem" 改通顺

前端：
- utils/types 里 Contest / User / Problem 三个别名删掉：Contest 原来指后台
  比赛、契约里同名的却是学生侧。现在 Contest = 学生侧、AdminContest = 后台，
  后台用户表单叫 AdminUserForm，题目详情直接用 ProblemDetail
- SubmissionInfo → ContestSubmissionInfo，免得和 submission.info 撞名
- utoa / atou → compressToBase64 / decompressFromBase64（实际是 zlib + base64），
  encode / decode → base64EncodeUtf8 / base64DecodeUtf8
- filterResult → toProblemRow、toProblemListItem → toAdminProblemRow，
  行字段 submission / rate → submissionCount / acRate
- 组件：Modal → AddFromLibraryModal、Form → EditorToolbar、
  ContestEditor → BasicEditor（题单也在用它）、rank 的 Index → RankMedal、
  Name → UserNameCell、Password → PasswordCell、ContestType → ContestAccessTag

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-27 16:08:21 +08:00
xuyueandClaude Opus 5 8b4d8899f9 feat(判题机): 自建镜像升级工具链，语言收敛到 C / C++ / Python
Deploy / deploy (push) Canceled after 0s
Details 
上游 QingdaoU/JudgeServer 停更在 2024-04（registry 上的 latest 和 1.6.1 是同一份
镜像，编译器停在 gcc-13），没有新版可拉，所以自己重编。docker/judge/ 是只改工具链
的 Dockerfile 分叉，server/ 和 Judger/ 从上游固定 commit b28aa56 拉，一行没动。

镜像 oj2-judge-2（不在任何 registry 上：本机 build.sh --save → scp → docker load）
- gcc/g++ 13 → 14.2，Python 3.12 → 3.13.5，都是 trixie 默认
- Go / JDK / Node 整套删掉：前端的题目语言复选框从来只给 C / C++ / Python / SQL，
  12 万条提交里 Java 44 条、Golang 15、JavaScript 3，全是很早以前的
- 体积 1.1GB → 433MB；默认走清华源，构建 12 分钟 → 40 秒（--no-mirror 换回官方）
- deploy.sh 加一道自检：镜像不在本机就中止，并打印该跑的三条命令

C 的编译参数加三个 -Wno-error（implicit-function-declaration / int-conversion /
incompatible-pointer-types）：gcc-14 把它们从 warning 提成了 error，而 -w 压不住。

语言值统一成 Python（迁移 0019 / 0020）
- 0019：Python3（104527 条提交）与 Python2（3 条）并成 Python，一并改掉 937 道题的
  languages、75 个 template 键、15 个 ast_rules 键、257 条 answers、1235 个用户的
  成就指标 _languages（languages_used 重算，总和 1928 → 1925，少的 3 个是同时用过
  两种 Python 的人）
- 0020：把 Java / JavaScript / Golang 从 84 道题的可选语言里摘掉 —— 不摘的话那些题
  的语言下拉还能选 Java，提交必 SYSTEM_ERROR
- 契约新增 normalizeLanguage() 别名表，判题侧一律走 judgeConfigFor()：旧客户端
  localStorage 里的 Python3、迁移前排进队列的任务都还能判；协作的语言归一也走它，
  否则上线那一刻学生页面里的 Python3 会静默落到 C
- 回滚要连数据一起回，只滚代码会让所有 Python 提交变 SYSTEM_ERROR

实跑
- 判题冒烟 docker/judge/smoke.ts 13 条全过：三种语言、六种状态码、gcc 宽松度
- 拿备份里的真实代码逐文件比对新旧镜像的编译结果，0 差异：C 提交 1951 份
  （1725 过 / 226 CE）、C++ 882 份、Python 2000 份、20 篇 C 教程的 93 个代码块。
  不加那三个 -Wno-error 的话，C 有 26 份会从能过变成 CE
- 迁移在灌了 12.4 万行真实数据的一次性库里跑过：0 残留、没有题目被清空；
  dev 库用真正的执行器跑通
- check:ast 56 个 target 全过，前后端 typecheck 均 0

顺带记下一个升级之前就有的坑（现在随 Go 一起消失，写在 README 里）：GOCACHE 指向
容器的 tmpfs，判题机重启后第一次 Go 提交是冷构建，Go 1.22 要 5.6 秒 CPU、超过 3 秒
的编译预算，于是重启后第一个交 Go 的学生必吃一次 CE，后面的人缓存热了又都正常。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-20 06:24:05 -06:00
xuyueandClaude Opus 5 ed56a209ea chore(格式): Prettier 统一到全仓，后端和契约一次性格式化
Deploy / deploy (push) Has been cancelled
Details 
原来只有 `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 ab47e71d6f refactor(契约): 出参不再 parse，后台老题详情和站内信页不再 500
Deploy / deploy (push) Has been cancelled
Details 
## 出参改 satisfies

出参是后端自己刚拼出来的字面量，TS 编译期已经验过；再 xxxSchema.parse({...}) 一遍
拿不到任何新信息，唯一可能失败的输入是库里的历史数据，而失败的代价是 500。136 处
全部撤掉，撤的时候当场炸出两个一直存在的线上故障：

- 后台打开任何一道没编辑过的题都是 500 —— problem.last_update_time 是全库唯一可空
  的列（961 道题里 470 道是 NULL），而 adminProblemSchema.lastUpdateTime 写的是
  z.string()；
- 收到过站内信的人打开消息页全是 500 —— embeddedSubmissionSchema 从
  submissionDetailSchema 继承了 problemDisplayId 却没 omit，路由只填了同义的
  problem；列表为空时才碰巧不炸，所以一直没人报。

两个都是读出侧校验自己造出来的故障，不是它拦住的故障。

## 校验责任挪回写入侧

- db/schema.ts：枚举型的列和几个形状确定的 JSONB 挂 .$type<>()（submission.result /
  .language、problem.difficulty / .languages / .template / .astRules / .sqlConfig /
  .sqlDisplay、achievement.rarity / .operator、exercise.type、reaction.type、
  tutorial.type、problemset.difficulty / .status、flowchart_submission.status、
  problemset_badge.condition_type、acm_contest_rank.submission_info）。只影响 TS、
  不产生 SQL，断言逐列拿根目录那份生产备份核过全量数据。
- createProblemRequestSchema.languages 收窄成 problemLanguageSchema，兑现
  problem.languages 列上的断言。
- 新增 routes/helpers.ts 的 asFilterValue()：query 筛选值（result / language /
  difficulty / status）要和收窄过的列比较时做纯类型交接，不加校验 —— 在这儿拦一道
  会把「筛出空列表」变成「筛条件被忽略、返回全部」。
- 判题产物（submission.info / statistic_info / exercise.data）照旧放行，形状真相
  在判题机那边；judge/sql、flowchart/run、events.ts 里对自家产物的 parse 一并撤掉。
- 仍然 parse 的只有 judge/events.ts 的 parseSubmissionEvent —— 从 Redis 收回来的
  报文是真边界，失败返回 null 而不是 500。

顺带清掉两处重复的真相：stringArray 原本在 routes/helpers.ts、routes/problem.ts、
routes/submission.ts 各有一份拷贝，5 个调用点全部只作用于 problem.languages，列有类型后
三份一起删；routes/site.ts 里和契约同名同形的本地 interface Quote 也删了 —— loadSentences
读入时已经逐字段守过，那处 parse 同样是多余的。

## 文档

CLAUDE.md 那一节从「契约收紧要挑地方」改写成「出参不 parse，用 satisfies」，写明
三处写入侧闸门（入参 safeParse 58 处、列上 $type、语义校验函数）；apps/web/CLAUDE.md
同步 —— 现在收紧字段的后果落在 tsc 编译期，但契约形状仍要对得上存量数据。

## 验证

- 生产备份全量：12.4 万条提交的 result 全在 -2..6,10、961 道题的 languages 均为合法
  数组、10050 条榜单条目形状全对，无一例外；
- tsc -p apps/api 与 vue-tsc --noEmit 均 exit 0；check:routes 检查 177 条路由，无遮蔽；
  前端 build、单二进制编译并在仓库目录之外启动均通过；
- 实跑 40+ 端点（学生端 / 后台 / AI / 榜单 / 题目回写往返），以及一次完整比赛 e2e：
  建比赛 → 复制题目 → 错解 → 正解，把 judge/run.ts 榜单写入的三个分支全走到
  （error_number 0→1、is_first_ac + ac_time 671、totalTime 1871 = 671 + 1×20×60），
  后台核查页的勾选与 404 分支一并验过，测试数据已清理；
- 两个 500 用抓到的真实响应对着改动前的契约复验：lastUpdateTime 收到 null、
  problemDisplayId 收到 undefined，改动后同样两个响应均通过。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH
 2026-09-10 18:14:05 -06:00
xuyueandClaude Opus 5 a5b57d8ab8 fix(判题): 任务被遗弃时给提交落一个终态，别永远停在「等待评分」 
judgeSubmission 自己的 try/catch 已经把正常路径上的异常都接住、落成 SYSTEM_ERROR
了，但队列的 failed 事件只有一行 console.error。判题队列没配 attempts（flowchart
队列配了 3），失败即终局；worker 进程被杀那种 —— 机房断电、容器 OOM、部署重启 ——
BullMQ 走完 stalled 重入队还是没人接，最后 emit failed，那条提交就永远停在
「等待评分」：学生看着转圈，教师统计里还占着一个「判题中」的名额。

加 failAbandonedSubmission()，在 failed 里调用，复用已有的 markSystemError（只动
PENDING/JUDGING，判完的和重判过的都不会被覆盖）。三种情况实跑验过：不存在的提交
安全返回、卡住的那条变成 result=5 并写入 err_info、已 AC 的那条没被动。

生产库里 3 条卡死的 PENDING（2022-11 / 2026-03 / 2026-04）都是旧栈时代留下的，
OJ2 上没有实例 —— 这次是把口子堵上，不是修已发生的故障。那 3 行和跟着差 1 的三道题
计数器还得手工处理。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd
 2026-09-08 18:29:30 -06:00
xuyueandClaude Opus 5 9d9e104df6 fix(题单): 进度记账挪到判题这一路，不再靠前端回调 
前端记账是这条链上最松的一环：SubmitCode.vue 看到 AC 就回调
PUT /problem-set-progress，而且只认路由参数里那一个题单。于是

  · 从普通题库入口做出同一道题 → 不计进度
  · 网络一抖、页面提前关掉      → 进度静默丢失
  · 一道题同时在两个已加入的题单里 → 只有进去的那个记上

旧栈为此专门有个管理命令 fix_problemset_progress 定期按实际提交补账 ——
2026-05-22 00:50 那次一分钟内跨 7 个题单的批量补进度就是它跑的。

改成判题落库之后由 judge/run.ts 记账（recordSolvedProblem），记进该用户**所有**已加入
且包含这道题的题单。位置在最后那条 publishSubmissionUpdate("finished") 之前，所以前端
收到「判完了」时进度已经落库，跳回题单页看到的就是新数据。前端那次回调删掉。

不按 visible / status 过滤：进度是学生自己的记录，老师把题单藏起来不该让它停止累积；
更要紧的是这条口径必须和补账工具一致，否则补账工具会永远「发现」差异。

实跑（本地起 api + worker 真判一次）：提交时**完全没带 problemSetId**，判完之后
progress 变成 1/1 100% 已完成、10 分、complete_time 落下、all_problems 奖章发出、
problemset_submission 也记上了。

## 补账那半

backfill-problemsets 前面加一道「按实际 AC 补进度」，移植自旧栈的
fix_problemset_progress，口径和 recordSolvedProblem 逐条对齐（非比赛提交、
ACCEPTED 或 AST_CHECK_FAILED、取最早那次）。补录的格子先并进 detail 再重算，
所以预演里的奖章名单是照着「补完账又重算过」的进度算的，和 --apply 的结果一致。

在生产快照上实跑：

  合计：补录 10 道题，进度 497 条要重算（完成 +23 / -0），奖章补发 56 条、收回 0 条
  已订正 11 个题单 → 复核通过
  user_badge 1180 → 1236，已完成 621 → 644，problemset_submission 7735 → 7745
  「未完成但有完成时间」仍是 4 条；重复跑幂等

补录的 10 道分布在题单 4/5/6/15/16（1/1/1/4/3），和离线独立算的数字逐个对上 ——
其中题单 15 那位 AC 了全部 12 题却一直显示未完成。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-09-01 00:01:38 -06:00
xuyueandClaude Opus 5 6ac458e6f3 refactor(WebSocket): 判题/流程图推送改用驼峰，去掉没人读的三个字段 
submission_id / time_cost / memory_cost / err_info 是 OJ2 两端自己定的线上格式，
没有第三方消费（/ws/submissions 只有 apps/web 一个客户端），没理由留着 snake。
flowchart 那条更别扭：同一个对象里 submission_id 是 snake、criteriaDetails 是驼峰。

三个字段直接删掉而不是改名 —— 它们是从 statistic_info 原样抄出来的一份，前端
一处都没读过（useSubmissionMonitor 只用 submissionId / result / status）。耗时和
错误信息在提交详情里本来就有，判完了去拉一次就是，不必让推送顺带背一份 JSONB
的形状。score 保留，它不涉及大小写。

**没动的都是有外部约束的**，别顺手一起改：

- 发给判题沙箱的请求体（language_config / max_cpu_time / max_memory /
  test_case_id / io_mode）和它回的字段（cpu_time / memory / test_case）——
  那是沙箱的 API，不是我们的
- 测试点 info 文件的键，沙箱直接读那个文件
- submission.statistic_info 里的 time_cost / err_info / ast_results ——
  判题机按这套写，12 万条历史提交就是这形状
- acm_problems_status、progress_detail 这些存量 JSONB
- AST 规则键（for_loop）、成就指标（accepted_count）、reaction 语义键 ——
  那是词汇表标识符不是字段名，for_loop 还要映射到 tree-sitter 的 while_statement

验证：起 dev 栈（api + worker + 沙箱），学生账号真提一次代码，抓 /ws/submissions
的帧：

    {"type":"submission_update","submissionId":"bf13b7f0…","result":6,"status":"pending"}
    {"type":"submission_update","submissionId":"bf13b7f0…","result":7,"status":"judging"}
    {"type":"submission_update","submissionId":"bf13b7f0…","result":-2,"status":"finished","score":0}

subscribe 帧也换成 submissionId 并被接受（否则会回一个 error 帧，没有）。
流程图那条路径要 AI 评分才跑得起来，本机没配，只做了类型检查。

前后端同一个 docker 栈一起构建部署，没有版本错配窗口。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 00:48:54 -06:00
xuyueandClaude Opus 5 f919d41199 refactor(契约): AST 代码要求收进契约，三份各写各的合成一份 
同一个形状原来在三个地方各定义了一份，三份都不一样：

  apps/api/src/judge/ast.ts        engine target outer inner label message exact min max
  apps/web/src/utils/types.ts      engine target                  message       min max
  AstRulesEditor.vue（本地）        engine target       label message exact min max
  ProblemContent.vue（本地）        engine target       label message exact min max

判题机那份是真的（evaluateRule 按 engine 分支读哪几个字段），契约里则压根没有，
`astRules: z.unknown()`。后果是后台编辑器写得出 label 和 exact、判题机也认，
但 utils/types.ts 那个类型描述不了它们 —— 生产库 12 道带 AST 规则的题里，
15 条规则带 label、6 条带 exact，全都在类型之外。

现在契约里一份 astRuleSchema，四处都指向它。engine 收成枚举，列全判题机
实现的十种。**存量数据核过**：12 道题逐条过新 schema，12/12 通过。

顺带三件：

- `astRules` 的响应和请求 schema 从 z.unknown() 换成 astRulesSchema。之前
  engine 写错一个字母能存进去，判题机 evaluateRule 走 `default: return null`
  静默跳过 —— 老师设了规则、规则不生效、没有任何提示。现在保存时就 400，
  错误信息把十个合法值列出来。
- judge/run.ts 的 astRulesForLanguage 原来是整片 `rules as AstRule[]` 硬转，
  改成逐条 safeParse：认不出的丢掉那一条，行为和 evaluateRule 的 default 分支
  一致，只是提前到读取处，也不再骗类型系统。
- 判题机实现了 must_have_nesting，但后台编辑器没有对应选项，目前只能手工造
  数据才用得上。枚举里留着并加了注释，没有顺手去补 UI（那是加功能不是清理）。

## 验证

tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过。
起服务实打：

- 把生产库那条带 label/exact 的规则种进本地库，后台题目详情 200、字段齐全；
  原样 PUT 回去 200，库里 label 和 exact 都在（旧类型描述不了的那两个）。
- engine 传 "must_do_magic" → 400，错误信息列出十个合法值。
- 直接调 checkAst：三条规则（两条合法 + 一条 engine 认不出）进去，判题机收下
  两条；两个 if/else 的代码 passed=true，一个的 passed=false，描述文案
  「if 条件 出现 2 次」正确用上了 label。

冒烟改动已还原（problem 2 的 ast_rules 复位成 null，测试标签删掉）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-25 23:15:52 -06:00
xuyueandClaude Opus 5 e3faa689e7 feat(阶段2补课): SQL 判题链路 + 最后两个后台端点 
新后端此前完全没有 SQL 判题（旧 judge/sql_runner.py 378 行 + sql_dispatcher.py
113 行无对应实现），阶段 2 纵切时漏了这条与沙箱完全不同的路径。

  judge/sql/engine.ts   判题核心，移植自 sql_runner.py，判定口径逐条对齐
  judge/sql/child.ts    子进程入口
  judge/sql/index.ts    父进程：spawn + 硬超时
  judge/run.ts          language === "SQL" 时分流，不经判题沙箱
  POST admin/sql-test-cases/preview    题目页展示数据预览
  POST admin/sql-test-cases/generate   AI 按标准答案倒推初始化脚本

题目保存时重新生成 sqlDisplay（对齐旧 generate_sql_display）：取测试点 1 的初始化
脚本 + 标准答案跑一遍，失败一律拦下不让保存 —— 展示数据直接决定学生看到的表结构
与期望结果，宁可不保存也不能存错的。

## 防护换了实现，逐条实测

bun:sqlite 没有 authorizer / progress_handler / setlimit，且实测 Worker.terminate()
杀不掉跑飞的查询（原生代码占着线程）。改用「WASM 引擎 + 独立子进程」：

  ATTACH  → WASM 无宿主文件系统绑定，结构上够不到（比旧的 authorizer 更强）
  查询题只读 → PRAGMA query_only=1
  超时    → 子进程外部 SIGKILL
  单值内存 → 子进程 ulimit -d

八条提交实测：正确→Accepted；列少一个/漏过滤→Wrong Answer；语法错误→Compile Error；
查询题里 INSERT→运行错误并说明；递归 CTE 死循环→CPU 超时；hex(zeroblob(2e8))→内存超限；
attach '/etc/passwd'→打不开。

## 踩到的两个坑（已写进 docs/specs/phase3-coverage.md）

1. ulimit 必须用 -d 不能用 -v。-v 限虚拟地址空间而 JS 引擎预留巨量地址，实测 -v 之下
   Bun 退出时有概率 panic（SIGILL），结果早已写出但进程异常终止，父进程读到空串
   误判成超时 —— 6 次里坏 2 次。换 -d 后 12/12 稳定。
2. 子进程写完结果直接 SIGKILL 自己，不走 process.exit()——后者仍有清理会撞限额。

至此 admin/api.ts 已无任何指向旧后端的调用。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 17:03:41 -06:00
xuyueandClaude Opus 5 8c00cdc947 feat(阶段3): oj 侧端点铺开（基线提交，未经评审） 
由外部 agent (Codex) 在本会话额度中断期间完成。原样提交作为基线，
后续修复单独成 commit，便于区分与回退。

覆盖 oj 侧 65 个端点，新增 9 组路由（account/achievement/ai/classroom/
content/contest/flowchart/problemset/site）与对应 Zod 契约。

已核验：tsc --noEmit 退出码 0；API 可启动；/api/problems 返回真实数据；
judge 与 flowchart worker 均 ready。
未核验：权限边界与数据泄露，评审进行中。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 01:25:36 -06:00
xuyue ec274419c3 Build Phase 2 judge vertical slice 2026-08-06 22:42:39 -06:00