|
|
f9354b0df1
|
fix(题单): 进度重算漏了分数和完成状态，奖章没人补发
Deploy / deploy (push) Has been cancelled
进度算法在学生路径和后台路径各写了一遍，于是各自漂了一段。后台那份
（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 |
|
|
|
a75c70c82d
|
perf(后端): 干掉 14 处 N+1 查询
Deploy / deploy (push) Has been cancelled
列表接口按行发查询是从阶段 3 一路带过来的写法：`Promise.all(rows.map(...))`
看着是并发的，但每行都往库里打一次，行数一多就是几百上千次往返。同样的模式
也散在几个后台批处理和写入路径里。全部改成「先收集 id，一条 inArray/group by
查回来建 Map」——`routes/problem.ts` 的 getProblemTags 早就是这么写的，这次
只是把剩下的地方对齐。
用户可见的列表：
- `GET /problem-sets` 每行 5 条（题目数/我的进度/奖章/已获奖章/创建者），
limit 上限 250 就是 1250 次往返。改成固定 5 条，与行数无关。
- `GET /contests` 每场比赛一条 creator 查询。后台的比赛列表本来就是 join
出来的，只有这条公开列表漏了。
- `GET /admin/problems`、`GET /admin/contests/:id/problems` 每题一条标签查询。
- `GET /admin/problem-sets` 每行 3 条；`.../badges` 每个奖章一条 count。
后台批处理：
- `refreshContestJoinedForAll` 原来是每个用户 1 条 count 加一个独立事务里的
insert/select for update/update。改成一条 group by 出全部用户的场次，再分批
upsert，`metrics || excluded.metrics` 是 jsonb 浅合并，只覆盖 contest_joined
一个键，其余指标原样保留 —— 合并在一条语句里完成，for update 那把锁不再需要。
- `rescanAchievement` 补发循环、`unlockAchievements`：命中的一次插完，
onConflictDoNothing 的 returning 就是真新解锁的那批，unlockCount 改成一次 +N。
- `resyncProgress` 逐行 UPDATE 改成一条，completed 用 least() 夹住。
写入路径：
- 标签解析抽出 normalizeTagNames + findTagsByName（一条 lower(name) IN），
新建题、改题、批量打标签三条路共用。
- 克隆比赛：题面一条 INSERT、标签一条 SELECT 加一条 INSERT。新旧题的对应
关系靠 _id 认，不依赖 returning 的行序。
- `POST /admin/website` 8 个键一条多行 upsert。
- 题单奖章判定一次插完。
`/ai/duration`：原来每个时间桶两条查询、桶之间还串行，一年 12 个桶 24 次往返。
改成先算桶、再一条查询把整段区间拉回来在内存里分桶。时间戳用
`extract(epoch) * 1000` 取毫秒回来比，别指望 Date.parse 认 pg 那个
`2026-08-12 00:00:00+00` 格式。**相邻桶首尾相接、两端闭区间**（落在边界上的
提交两个桶都算）这条旧语义是照搬的，不要顺手改成半开区间。
验证：本机起 dev 栈，造了覆盖各分支的种子数据（创建者重复的题单、零题目/零
奖章的题单、completed > total 的脏进度、除不尽的百分比、大小写混写的已有标签、
带/不带标签的比赛题、正好落在分桶边界上的提交），旧代码跑一遍、新代码跑一遍：
- 51 个接口响应逐字节一致
- 12 张表的快照逐行一致（唯一差别是 progress_detail 里的 submit_time 墙钟值）
- 打开 log_statement=all 数过条数，例如 `GET /admin/problems` 20 道题
24 → 5，`GET /problem-sets` 28 → 8，`/ai/duration` years:1 28 → 5，
202 个用户的成就补发 1828 → 614
一处可观察的行为变化：补发现在整批共用一个 unlockTime，原来是每人一个
new Date()。rescanAchievement 上方的注释本来就写着补发会给几百人盖同一个
时间戳、前端据此只显示「已获得」不显示日期，所以这个方向是对的。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 23:43:57 -06:00 |
|
|
|
0f94e7ecbd
|
fix(阶段4): 两份独立安全评审的 Critical/Important 全部修掉
## 权限边界评审（后台 86 个 handler）
守卫本身一个没漏，问题全在对象级归属校验：
- C1 跨题单删奖章：先按 (id, problemsetId) 校验奖章归属再删，
否则拿自己的题单 id + 别人的奖章 id 就能把别人的 user_badge 删掉
- C2 make-public 无归属校验：补 canEdit，越权者拿不到题面
- I1 两个分析端点被 `/problems/:id` 遮蔽 —— Hono 按注册顺序匹配，
不是静态优先。挪到 `/problem-analytics/*`
- I2 from-public 只校验目标比赛归属：源题也必须是公开题库题
- I3 克隆比赛回传原比赛明文密码：克隆一律 password: null
- I4 upload-image 守卫比旧后端严，教师写题面会 403：收回 requireAdmin
两个互不可见的教师账号实跑复验，六条全部拦住。
## SQL 判题沙箱评审
- I-1 查询题只读被一句 `PRAGMA query_only=0` 关掉，实测 DML 拿到 AC。
query_only 自己就是个 PRAGMA，旧实现靠 authorizer 把 SQLITE_PRAGMA
一律拒了才没这个洞。现在 runStudent 逐语句拦 PRAGMA（用
sqlite3_normalized_sql 判关键字，注释和大小写由 SQLite 抹平），
并在每条语句前重放 query_only 和 max_page_count 兜底。
顺带修掉 M-1 里 max_page_count 学生可自行调大的部分。
- I-2 单条语句进了 step() 就打断不了，只能等父进程 SIGKILL，
而兜底时限是整个作业一口价 25s —— 1s 限的题要 26s 才判 TLE，
判题池只有 2 个槽，几发死循环就能把所有人堵住。
改成分阶段：子进程用 stderr 报 prepare/student/display，
父进程边读边换表，一进学生 SQL 就把兜底收到「题目时限 + 2s」。
实测 26s → 3.06s。
归因也跟着修了：卡在受信脚本（出题人的初始化脚本、标准答案）
现在报 SYSTEM_ERROR，不再当成学生超时甩 TLE。
engine.ts 头部那张防护对照表按实测重写 —— 原来那版把 query_only
写成等价于 authorizer 白名单，是不成立的。另记一笔：stock sql.js 的
wasm 没导出 progress_handler / interrupt / set_authorizer / limit，
想要得自己编，别再去翻了。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 21:59:42 -06:00 |
|
|
|
5e0229db12
|
feat(阶段4): 题单管理（题目 / 奖章 / 进度三层）
GET/POST admin/problem-sets
GET/PUT/DELETE admin/problem-sets/:id
PUT admin/problem-sets/:id/visibility （取反语义，与旧一致）
PUT admin/problem-sets/:id/status
GET/POST admin/problem-sets/:id/problems
PUT/DELETE admin/problem-sets/:id/problems/:itemId
GET/POST admin/problem-sets/:id/badges
PUT/DELETE admin/problem-sets/:id/badges/:badgeId
GET admin/problem-sets/:id/progress
DELETE admin/problem-sets/:id/progress/:userId
修掉旧后端三个问题：
1. **后台列表写死了 visible=True，可它同时又提供「切换可见性」的接口** ——
一旦把题单设成不可见，它就从后台列表消失，再也没法在界面上改回来。
新实现不按 visible 过滤，后台能看见自己管的全部题单。实测取反两次仍在列表里。
2. **加题/删题/改分值后不重算学生进度**。往题单里加一道题，学生那边的
totalProblemsCount 还是老数字，进度百分比因此偏高，甚至已「完成」的人分母变了
却还标着完成。新实现加了 resyncProgress，实测 2/2 加一道题后变成 2/3 = 66.67%。
只重算分母与百分比，不碰 completeTime —— 已完成过的事实不因加题而撤销。
3. 把人踢出题单时一并收回他基于这份题单拿到的奖章，否则奖章悬空。
奖章重算对齐旧 recalculate_user_badges（那边靠 post_save 信号，这里显式调）：
只增删差集、保留已有记录的 earnedTime，否则每改一次条件所有人的获得时间都会
刷新成今天。实测 all_problems 建成时补发 1 人 → 加题后收回 → 改成
problem_count>=2 后重新发出 → 踢人后收回。
删题单要按序清五张子表（全是 NO ACTION 外键）：user_badge 挂在 problemset_badge
上，得先于 badge 删。
实测：学生 403；重复加题 409、加不存在的题 404、野状态/野奖章条件 400；
级联删除后五张表全为 0。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 16:25:14 -06:00 |
|
