xuyue/OJ2
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
293 Commits 1 Branch 0 Tags
640679497184872b6217abbcdb3426c7be4ba2d4
Commit Graph
6 Commits
Author SHA1 Message Date
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 5eee13fe81 chore: 删掉两个跑完的一次性订正脚本，recount 留着
Deploy / deploy (push) Has been cancelled
Details 
fix-achievement-hours 订正的是时区丢失那两周误发的「夜猫子」「早起的鸟儿」，
2026-09-14 已跑完（修正 148 行 · 撤回 60 条），根因修在代码里之后不会再产生；
backfill-problemsets 补的三笔题单历史欠账也已结清，进度记账现在在判题这一路。
两个子命令、两条 npm 脚本一并去掉，services/problemset.ts 的 badgeHolderDiff
只服务于补发脚本，删完 0 处引用，一起清掉。

recount 留着 —— 反范式计数列会被重判、删提交带偏，是会复发的漂移，
补一条 npm 脚本（原来只有子命令）。

docs/timezone.md 里那节改成「账已平、脚本已删」，但保住那条教训：
unlockAchievements 是纯阈值比较，只删 user_achievement 不修 metrics 的话，
学生下次提交就把同一个成就原样再发一次。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-16 08:03:57 -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 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
xuyueandClaude Opus 5 d7a6414735 fix(题单): complete_time 翻回「只设不清」；完成题单后那个必然报错的 tab 
三件事，都是上一轮结论没查扎实留下的。

## complete_time

f9354b0 把「退回未完成时清空 complete_time」定成两边统一的行为，理由写的是
「快照里 complete_time 非空 ⟺ is_completed」。那个检查只做了一个方向（已完成但
没有完成时间 = 0 条），反方向没查 —— 实际有 4 条 is_completed=false 却留着
complete_time，全在题单 8：那批人 2025-11-14 在它还只有 6 题时完成过，老师后来
加到 12 题，进度退回未完成，完成时间保留了下来。

旧栈是故意不清的（problemset/models.py:218 只有 `if is_completed and not
complete_time` 这一条赋值），语义是「曾经完成于」。清空是重写时在学生路径上引入的，
上一版又把它推广到了后台路径。

翻回只设不清。「未完成 + 有完成时间」是允许的组合。反过来清空的代价不可逆：往一个
100 人已完成的题单里加一道题、再改主意删掉，这 100 个人的历史完成时间就一起被冲成
「现在」—— 上一轮的实跑已经在题单 9 上复现过。

## 两处注释订正

「旧后端不做加题后的重算」这个说法是错的，本仓早先的注释里有，上一版我照搬进了
services/problemset.ts 和提交信息。旧栈用 signals 做了，而且两件事都做：
problemset/signals.py 在 ProblemSetProblem 的 post_save / post_delete 上重算全部
参与者进度、再重算该题单全部奖章。重写时 views 里翻不到显式调用就当成没做，于是
奖章那一半漏了 —— 53 条应发未发正是这么来的。

另外补上 53 条里那 23 条的出处：旧栈的管理命令 fix_problemset_progress 按实际 AC
补 progress_detail，而 signals 不挂在 Progress 上，所以进度补了、奖章没补。

## 用户进度 tab

detail.vue 的 showTabs 写的是「超管 或 自己完成了题单」，而它渲染的
UserProgressView 调的是 requireTeacher 的接口。两边正好错开：

- 学生做完题单 → tab 出现 → 点进去 403（实跑确认：已完成该题单的 student 拿到
  403 permission-denied，devadmin 拿到 200）。而 loadUserProgress 没有 try/catch、
  loading.value = false 又写在 await 之后，转圈永远停不下来。
- Teacher Admin 看不到这一栏，尽管他们才是它的目标用户、也是唯一调得动的角色。

条件换成 isTeacherOrAbove，取数补 try/finally。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 08:42:40 -06:00
xuyueandClaude Opus 5 f9354b0df1 fix(题单): 进度重算漏了分数和完成状态，奖章没人补发
Deploy / deploy (push) Has been cancelled
Details 
进度算法在学生路径和后台路径各写了一遍，于是各自漂了一段。后台那份
（resyncProgress）名叫「把所有参与者的进度重算一遍」，实际只更新分母和百分比：

- 不碰 total_score。改题目分值时专门调了它，函数体里却没这个字段，score 类奖章
  因此按陈旧分数判定。
- 不碰 is_completed。加一道题之后分母变大、百分比掉下来，人还标着「已完成」。
- 不清理 progress_detail。删掉一道题之后 least(completed, total) 只保证不超过分母，
  会把没做的题算成做了 —— 3 题的题单只做出 C，删掉 C 就变成 1/2 = 50%。
- 不重算奖章。题目集一变 all_problems 的达标面就变了，没有任何地方补发。

最后一条攒下了实打实的欠账：8-07 的快照里 53 条应发未发，涉及 30 名学生，误发 0 条。
其中 23 条来自 2026-05-22 00:50 那次一分钟内跨 7 个题单的批量补进度 —— 进度补了，
奖章没人回头判。

两边不再分叉的唯一办法是只留一处算法，所以抽出 services/problemset.ts：
computeProgress 是纯函数，学生做出一题和后台改题目都只是调用者；
eligibleForBadge / recalculateBadge / resyncProgress 一并搬过来，补发脚本才能复用
同一套判定。批量写回仍是一条 UPDATE ... FROM (VALUES ...)，没退回逐行往返。

顺带修掉空题单的坑：isCompleted 加了 total > 0 前提。原来 0 === 0 也成立，老师先建
题单、学生先加入、题目后加，加入那一刻就写下 complete_time 并计进「完成题单数」成就，
而且后面补上题目也不会自愈。

一处行为变化：退回未完成时 complete_time 会清空。后台那份原来保留旧时间，学生那份
一直是清空的，统一成后者 —— 否则同一行会出现「未完成 + 有完成时间」，破坏现有数据里
「complete_time 非空 ⟺ is_completed」这条不变量。代价是加题再删题会把历史完成时间
洗成「现在」。

scripts/backfill-problemset-badges.ts 补历史欠账，默认只读预演，--apply 才落库。
只要存在误发就拒绝执行并打出名单，要连收回一起做得显式加 --allow-revoke ——
recalculateBadge 的删除是真删，user_badge 的 earned_time 没有别处备份。

在生产快照上实跑：补发 1180 → 1233 条，复核全部一致，历史 earned_time 未被刷新；
resyncProgress 对题单 9（7 题 / 117 人 / 100 人完成）加题后正确退回 0 人完成并收回
100 枚奖章，删题后完整恢复；改题目分值 10→20 使总分和 7460 → 8590，正好 +113×10。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 08:23:38 -06:00