83 Commits

Author	SHA1	Message	Date
yuetsh	26b23aa7c0	fix(统计): 「提交记录」列出所有交过的人，不再只有做完的 ... 统计面板那张表原来只给 `isDone` 为真的人，于是一次没对的学生连同他的提交 在面板里根本不存在——tab 却叫「提交记录」，看起来就像统计只认成功的提交。 - `data` 改成给窗口里交过东西的全部人，每行带 `done`；「完成人数」和完成度 跟着 `done` 数，不是 `data.length`，两个数字口径不变。 - 表格加「完成」列区分两种人；展开行拉的仍是那个人的全部提交（items 接口 本来就不按结果过滤），对错都在里面。 - 「交了没全对」那一栏原来无条件按花名册取，不填班级/用户名时花名册为空、 整栏跟着空掉，这批人两栏都不在。改成没有花名册时退回「有提交但没做完的 全部普通学生」，教师和禁用账号仍然排除；全站视图里保留完整用户名不剥班级 前缀。「还没交」那一栏没有花名册是真算不出来，仍然为空。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PZbWEaPCnGvmdfNFpPFNGb	2026-09-08 23:52:34 -06:00
yuetsh	6bef55904f	fix(题目分析): 「卡住的题」只看公共题，别把比赛题也算进来 ... 这条查询原来一个 where 都没有，比赛题一起进榜。隔壁 ac-trend 在同一个文件、同一块 面板，isNull(contestId) 写得明明白白，所以判定是漏写而不是口径选择。 比赛题的题号是每场比赛各自从 1 开始编的（快照里 61 道不同的题都叫「1」、61 道叫 「2」），一旦挤进前 40，那一行显示的题号会指向一道根本不存在的公共题。眼下还没 发生：前 40 的门槛是 97 人卡住，比赛题最多的一道是 59 人 —— 但两个班一起考的场次 有 95 人，撞上一道难题就够得着。 对公共题的数字没有任何影响：比赛提交挂的是比赛自己的 problem 行（快照实测两个方向 的交叉都是 0 条），公共题那一行本来就只统计自己的提交。实跑接口逐行比对，改前改后 前 40 集合完全一致，只有三处并列名次的先后不同 —— 那是这条查询本来就没有确定性 tiebreaker，并列的题在两次刷新之间也会自己换位置。 顺带能用上 0013 的 submission_public_metrics_idx：183ms / 18646 buffers → 80ms / 788。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd	2026-09-08 18:30:05 -06:00
yuetsh	64ad6139f5	fix(后台用户): 删账号前拦住还有提交的人，改名回填按 user_id ... 两处都是「提交与用户的归属」在写路径上没维护住。 删账号：处理器那段注释早就点到了 submission.user_id 没有外键、全连坐会留下孤儿行， 但只把它当成「不改成 CASCADE」的理由，没有加对应的检查。结果是报错文案里写着 「该用户还有提交、题目等历史数据」，而提交恰恰是唯一拦不住的那一类 —— 只交过题、 没拿过成就没进过题单没参加过比赛的学生照样删得掉。 生产快照实测复现：删 id=1454（李若菡，13 条提交）返回 200 deleted:1，用户没了、 13 条提交留在库里，孤儿总数从 935 涨到 948。那 935 条就是这么攒出来的（28 个已删 账号）。线上今天还有 5 个这样能删的学生。 补一次提交查询把它拦下来，和 delete 放同一个事务里免得中间正好交了一发。文案一个 字没改 —— 它本来就是对的，缺的是兑现它的代码。混批删除整批回滚，干净的那个也留着。 存量 935 条不动：四条读路径现在都用 leftJoin 兜住了，列表显示冻结的名字、不出死链， 统计按 user_id 聚合他们本来就不在花名册里。加外键得先清历史数据，收益只有「以后 不再产生」，而那一半这次已经解决了。 改名回填：条件从「等于旧用户名」改成按 user_id。前者只改得动当前正好还等于旧名的 行，一个已经漂移过的账号再改一次名，更早那批仍然改不动 —— 库里 726 条挂着旧名字的 提交就是旧栈时代这么留下的，之后每次改名都从它身边绕过去。实测拿 user 2039 验过： user 表叫 ks248吴紫妍、13 条提交挂着 ks24数媒1班ks吴紫妍，老写法一行都匹配不上， 改成按 user_id 之后一次拉平。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd	2026-09-08 18:29:19 -06:00
yuetsh	a89eed7bdd	fix(提交统计): 按 user_id 归属提交，不再按提交时冻结的用户名 ... submission.username 是提交那一刻的快照。教师统计全程拿它当主键用 —— ilike 过滤、 group by、再拿结果去 user 表 join 班级 —— 学生改名之后旧提交还挂着旧名字，一条都 匹配不上。 生产快照实测（2026-09-08）：24 级数媒两个班改成编号制用户名之后，查 ks249 旧口径 0 条、新口径 7 条，整个班 48 人全掉进「一条没交」；查 ks248 是 20 条 / 54 条， 13 个人的成绩查不出来。ks248林依晨那 8 条提交原来一条看不到，人在「一条没交」栏， 现在落到「交了没完成」并带出最后一次失败在 1082 题。 四条路径一起改： - /submissions/statistics 的过滤、聚合、花名册全部改按 user_id，用户名从 user 表 join 出来。已删号的学生 user 表里没有行，退回提交里冻结的名字（personCount 那句兜底就是给这种情况的） - /submissions/statistics/items 展开行先把用户名解析成 user_id - /submissions 和 /contests/:id/submissions 的用户名筛选取并集：user_id 匹配到的 账号，加上按冻结用户名匹配的（已删号的 28 个账号只剩这一份名字，顺带「按记得的 旧名字搜」也还查得到）。列表显示的名字改成当前用户名，否则筛 ks248 出来一堆写着 ks24数媒1班ks的行，看着像筛错了 - /rankings/activity 同样按 user_id 分组。这条眼下是预防性的：改过名又有 AC 记录的 4 个人只有 1~2 题，够不到前 10，但真上榜会显示旧名字或被拆成两条 顺带把统计接口的四次全表扫换成索引扫：ilike 走不了索引，换成 user_id in (...) 之后单条 18448 → 537 buffers，整个接口查一个班 120~250ms → 10ms 上下。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd	2026-09-08 18:29:02 -06:00
yuetsh	9c5a1d551d	perf(教师统计): 展开行的明细改成按需拉，统计响应不再背着 4.9 万行没人看的数据 ... 上一版把明细收成「只取有 AC 的人、每人最近 50 条」，拿生产快照（12.4 万条提交） 实测下来只从 105631 行降到 49108 行 —— 2.1 倍，不是一个数量级。原因是绝大多数人 本来就不到 50 条，每人截断那道闸在真实分布上基本没咬到，最坏情况响应体仍有 ~2.4MB。 真正的问题是形状不对：表格一次只展开一行（updateExpandedRowKeys 只留最后一个 key）， 却给 1900 个人各准备了一份。所以明细整个从统计响应里拿掉，改成展开时按需拉： - 新端点 `GET /submissions/statistics/items`，要用户名 + 同一套时间窗和题号。 用户名这里是**精确匹配**，不是统计接口那种 ilike —— 那边填 ks251 要圈出整个班， 这边是「点开的这一行是谁」。上限 200 条，多取一条来判断 truncated，被截断时 展开行里说明「只显示最近 200 条」，免得老师以为这人就交了这么多。 - 时间窗和题号抽成共用的 statisticsScope，两个接口必须同一个范围，否则展开行 看到的是另一个窗口的数据。 - 前端按人缓存，收起再展开不重拉；每次重新统计（含 15 秒自动刷新）清缓存， 并把当前展开着的那一行重拉一遍 —— 展开行跟着一起活着，不然刷新之后上面的数 变了、下面的明细还是老的。 - 去重放在 loadItems 里：点一行会同时走 rowProps 的 onClick 和表格的 update:expanded-row-keys，两边都想拉，改之前真发出了两条一模一样的请求。 顺带把 submissionItems 从 submissionStatisticsUserSchema 里删掉。 生产快照上的验证（12.4 万条提交 / 1956 用户 / 961 题，恢复进一次性容器跑完即删）： - 最坏情况（全部时段 + 不填条件）少搬 49108 行，约 2.4MB - 真实课堂量级（最忙的一小时：583 条提交 / 81 人）四条查询分别是 主聚合 45ms、明细 6.5ms、语法未过 2.4ms、最近错因 <1ms - 「已解决」那条口径修正的实际影响：13.3% 的「人×题」有重复 AC，同一题最多 AC 45 次； 按人看最夸张的是 419 条 AC 其实只有 38 道题 - 语法要求的题 15 道、result=10 共 57 条，其中「最后也没改对」的 18 个人×题 —— 角标会出现，但稀有 浏览器实跑：展开前不发明细请求；展开后 1 条、12 个按钮；收起 +0、再展开 +0（走缓存）； 自动刷新时统计与明细 1:1 配对、间隔 15 秒，没有重复请求。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd	2026-09-08 05:43:32 -06:00
yuetsh	f66bafafaf	feat(教师统计): 提交统计面板返修 —— 统计口径、未完成分两栏、多题、自动刷新 ... 排查这个面板时发现的一串问题和缺口，一起修掉。改动集中在 `GET /submissions/statistics` 和 `StatisticsPanel.vue`，两边互相咬着， 拆不成独立的 commit。 **「已解决」数的不是题数**（真在显示错数字）。`count(*) filter (accepted)` 按用户名分组、没有 distinct problem_id，同一道题重复 AC 会重复计数。查单道题时 看不出来，老师查「这节课全班」时「已解决 5」可能是同一道题交了 5 次。新增 `solvedCount = count(distinct problem_id) filter (accepted)`，表格那一列换成它； `acceptedCount` 保留，正确率的分子仍然是提交条数。 **正确率把判题中的算进了分母**。PENDING / JUDGING 进分母不进分子，全班同时交卷的 那几秒正确率凭空掉一截 —— 而老师盯着看的就是这个数。分母改成判完的条数， `UNJUDGED_RESULTS` 提到 judge/status.ts 共用。总提交仍是全部条数（交了就算交过， 否则人数口径会跟着变，正在判的学生会掉进「没交」名单），另外下发 `judgingCount`， 非零时面板多显示一块「判题中」，三个数字才对得上。 **「未完成」实际是「一次没交」**。做了但一次没对的学生既不在「完成人数」也不在 未完成名单，等于从屏幕上消失 —— 而那恰恰是最该去看一眼的人。新增 `dataAttempted`，未完成栏拆成「还没交」/「交了没对」两组，tab 计数是两者之和。 请假隐藏对两组同时生效：他们同样占着班级人数这个分母，只藏一半会把完成度算错。 **点名字能看到错在哪**。`dataAttempted` 带上最近一条提交的题号、状态和 `statistic_info.err_info`（截断 400 字），点名字弹出来，还能一步跳到代码。 老师不用再切到提交列表、翻到这个人、点开代码。 **支持一次查几道题**。题号框接受 `1001,1005,1010`（中英文逗号、分号、空格都当 分隔符，投影前手敲不该因为打了全角逗号就查不出来），有一个题号不存在就整体 404。 **完成 = 这几道全解决**；只填一道时和原来完全等价，不填题号时退回「至少做出一道」。 差一道的人落在「交了没全对」里，名字后面缀 `2/3题`。 **零提交时整块面板消失**。判空条件是 `count.total > 0`，可一节课刚开始一条提交都 没有、后端已经把整份花名册当作「未完成」返回了 —— 最该看名单的时刻反而只显示 「暂无数据」。流程图那边更彻底：`/flowcharts/statistics` 的零提交分支把 `dataUnaccepted` 写死成空数组，名单压根没下发。 **面板不会自己刷新**。打开是空的、要点一次按钮，拿到的是那一刻的快照。改成打开即查 + 每 15 秒滚动重查，页面切到后台就停，关掉面板随组件卸载停掉。上一次没回来就跳过 这一次。班级从手打 `ks251` 换成下拉（选项来自网站配置的 class_list，和登录框同一份）， 保留自由输入，查过的班级记进 localStorage 下次带上 —— 机房电脑一台对一个班。 **明细查询没有 LIMIT**。展开行用的 submissionItems 原来把窗口内**全部**提交捞进内存 再原样序列化，「全部时段 + 不填条件」就是十几万条。改成只取有 AC 的人、每人最近 50 条， 截断用窗口函数发生在数据库侧；表格「提交数」仍是真实总数。 **顺带**：`personRate` 前端从来没读过（完成度是前端按「减掉请假人数的分母」自己算的）， 从契约里删掉；「语法未过」的题数单列出来（AST_CHECK_FAILED 全站仍然算通过，口径没动， 只是让老师看得见谁是绕过语法要求做出来的，那批人教学上没达标）。 实跑验证（dev 全栈 + 浏览器）： - 已解决：student 两条 AC 都在题号 5 上 —— 改前显示 2，改后显示 1 - 正确率：临时把两条改成 PENDING/JUDGING，12 条提交 2 条通过 —— 16.67% → 20%， 面板多出「判题中 2」，表格显示「12（2 条判题中）」 - 未完成两栏：student2 没交、student 交了 12 次没对，请假隐藏 student 后 班级人数 2→1、tab 2→1、出现「恢复 1 位」 - 错因弹层：点 student 弹出「最近一次：1020 · 编译失败 / Test case not found / 看代码」 - 多题：`1004` 完成 1 人；`1004,1005` 完成 0 人、交了没全对 student 1/2题 8次； 全角逗号同上；`1004,9999` 报 `Problem 9999 does not exist` - 自动刷新：打开即发请求，之后 04:44:22 → 04:44:36 → 04:44:51 → 04:45:06 每 15 秒 一次且窗口跟着滚；关掉面板后 20 秒请求数不再增长 - 班级下拉：选「25计算机1班」→ ks251，重开面板自动带上并立刻查 tsc / vue-tsc / check:routes 全过。验证用的 dev 库改动已还原。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd	2026-09-08 05:20:51 -06:00
yuetsh	6a438872b9	feat(排行榜): 页头显示当前在线人数，在线绿点只给老师 ... 新增匿名可读的 GET /api/site/online，一条 ZCOUNT 让 Redis 自己数， 不拉成员、也不写（清理过期成员留给后台列表，匿名接口不带写操作）。 榜单页进页面拉一次，为 0 时不显示。 /rankings/users 的 isOnline 是三态：null 表示「这个调用方不该知道」， 只有老师及以上拿到 true/false。写成普通 boolean 的话学生看到的 false 和真的离线分不开，等于默认把每个人的在线状态摊给全校同学看。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017xu912Rv5JUUuy6MqMcQW2	2026-09-07 19:36:12 -06:00
yuetsh	856b7a280e	feat(后台用户): 新增「在线优先」排序，列表直接显示在线标记 ... 在线状态库里没有、会话也判定不了 —— session 的 TTL 是 7 天且每次请求续期， 「有会话」只说明这人一周内来过。新开一个 Redis sorted set（auth/presence.ts） 记最后活动时间，5 分钟内有活动算在线。 写入全搭在已有的 pipeline 上，不多一趟往返：登录、每个带鉴权请求的续期、 以及 touchSession —— 只挂着 WebSocket 不发请求的人靠最后这条，sweepSessions 每 60 秒一轮，所以窗口取 5 分钟，明显大于那个间隔。登出、改密码、禁用账号 会立刻把人摘掉；过期成员在后台读列表时顺手清理（整个 key 不能设 TTL， ZADD 不重置 key 的 TTL，到期会把还在线的人一起抹掉）。 排序 orderBy=-online 先捞在线 id，SQL 里 case when 分两档，档内继续按 最近登录排；没人在线时那个 case 恒等于 1，直接省掉。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017xu912Rv5JUUuy6MqMcQW2	2026-09-07 19:30:45 -06:00
yuetsh	5222e012e1	fix(比赛): 修四处 —— 倒计时两倍速、排名不自动刷新、题目状态恒空、比赛隐藏后审核页取不到代码 ... 查比赛功能时实跑出来的四个问题，都在这一条里修掉： **倒计时两倍速**（store/contest.ts）。init() 里 setInterval 之前不清旧表，而 detail.vue 在「未开始 → 进行中」那一刻会再 init 一次（为了捞开赛后才拿得到的题）， 于是两个 interval 一起给 now 加 1000。学生赛前挂着页面就会中招：一场 60 分钟的 比赛，真过了 30 分钟页面就显示「已结束」、倒计时归零，而服务端还在正常收提交。 ojnext 里就有，是原样搬过来的。 **排名页「开启自动刷新」开着但不刷新**（contest/pages/rank.vue）。useIntervalFn 传的是 immediate: false，而 watch(autoRefresh) 只在开关变化时才 resume —— 开关初值就是 true、进页面不产生变化，表从没启动过，得手动关一次再开。改成 watchEffect，由「开关 + 比赛进行中」共同驱动，顺带不再在赛后空转轮询。同样来自 ojnext。 **比赛题的 myStatus 恒为 null**（routes/contest.ts）。判题其实把状态记进了 user_profile 的 acm_problems_status.contest_problems，只是这两条路由硬编码下发 空值，于是题目页的「状态」列永远是「未做」，赛后也不恢复。旧后端在赛后/管理员 视角是给的，这是回归。不按赛中赛后分档：这是学生自己的判题结果，不泄露别人任何 信息（旧后端赛中不给，只是因为它整条路换了个 serializer）。 **比赛一隐藏，审核页的「查看代码」必 404**（services/contest.ts）。acm-helper 故意不卡 visible（赛后核查恰恰发生在比赛收起来之后），它调的比赛提交列表却卡着， 两边对不上。findVisibleContest 换成 findAccessibleContest：公开的谁都取得到， 隐藏的只有比赛管理员取得到，学生看隐藏比赛照旧 404。 实跑验证（dev 全栈，判题走临时 worker 绕开本机 token 不一致）： - 浏览器跨过开赛时刻挂着不动 —— 墙钟 20.0 秒，倒计时正好减 20 秒（原来会减 40）。 - 排名页停在「无数据」，另一账号提交一发 AC，5 秒内表格自己长出 `1 student2 1/3 0:00:42`，没刷新页面。 - 学生 AC 后列表和详情都回 myStatus: 0，没做过的另一个学生仍是 null，匿名照旧 401。 - 比赛隐藏 + 已结束：出题人 detail / problems / rank / submissions / acm-helper 全 200，学生这 5 条全 404，提交也 404，隐藏比赛不进公开列表。 - 排名记账口径未受影响：10 次提交（8 编译失败 + 2 AC）落库 submission_number=9、 accepted_number=1、total_time=231=ac_time、is_first_ac=true。 tsc / vue-tsc / check:routes（175 条无遮蔽）均干净，测试数据已清库。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017xu912Rv5JUUuy6MqMcQW2	2026-09-07 19:19:29 -06:00
yuetsh	25b86ec17e	refactor(提交): 删掉从来没用起来的「提交互相可见」 ... problem.share_submission（题目级）和 submission.shared（单条）两个开关，连同 判定分支一起删掉。 生产备份（2026-08-07）里的实际用量：956 道题只有 2 道开过 share_submission， 还都是 contest_id=1 的比赛题 —— 比赛未结束时那条分支根本走不到，等于一天都没 生效过。123140 条提交里 shared=true 的有 40 条，39 条在 2022 年、1 条在 2023-03-30，之后近三年零使用；出题页从来没给过题目级开关，单条分享的入口在更早 那版前端上，ojnext 和 OJ2 都没搬过来，OJ2 里 PUT /submissions/:id 一个调用方 都没有。 canViewSubmission 剩下三条：本人 / 管理员（比赛中的 Student Admin 除外）/ 本题 作者，其余一律看不到。结尾的 `shareSubmission || shared` 没了；它上面那条「比赛 未结束一律不给」也一并去掉 —— 走到那里的必然不是这三种人，现在无论比赛与否都是 false，留着是重复的。allowShared 参数随之消失，它唯一的用途就是分享开关的归属 校验。 一并删掉：PUT /submissions/:id、响应里的 shared / canUnshare（列表、详情、站内 信内嵌三处）、题目详情与后台题目里的 shareSubmission、shareSubmissionRequestSchema， 以及新建提交时那句 shared: false（列上本来就有 default false）。 两个数据库列保留不删，只在 schema.ts 上注明已停用：删列是破坏性迁移，而留着不读 不写零成本，还留着那 40 条的历史痕迹。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XvmqDsZNyUo9P3sFQtoWVB	2026-09-07 07:18:41 -06:00
yuetsh	498fc1ceca	fix(后台): 会话吊销、导入查重、练习题校验，以及一批后台页面的小毛病 ... 后台代码审查后的一批修复。 后端： - 改密码 / 重置密码 / 禁用账号现在真的把该用户所有设备的会话删掉。原来只 publishSessionRevoked 广播断 WebSocket，HTTP 拿着旧 cookie 照样能用到会话 自然过期 —— 给被盗用的账号改密码等于没改。为此在 Redis 里补了反向索引 user-sessions:<id>（createSession 写入、登出和失效路径清理、跟着会话续期）。 - 导入用户补齐校验：邮箱走 z.email()、批内查重、库内查重，用户名和邮箱各报各的； 用户名和邮箱都归一成小写，和登录的 lower(username) 比较口径对齐。以前导入这条 路什么都不查，而前端占位邮箱按「班级+批内序号」拼，同一个班导第二批必然重号， 那两个账号从此在后台保存一次就撞 409、再也改不动。前端生成的占位邮箱同步加了 每批随机后缀。 - PUT /users/:id 的邮箱查重改比 lower(email)，存量大小写混着的数据也能拦住。 - 删用户的裸 catch 收窄成只认外键冲突 23503（顺 cause 链找，drizzle 0.45 把驱动 错误包了一层），别的错照常抛 500，不再把连接故障说成「该用户还有历史数据」。 - 练习题 data 补语义校验（services/exercise.ts）：没有 {{空位}} 的填空题、空选项的 选择题、越界的下标等一律拒收。以前后端零校验，坏数据只有学生端会撞到。 - PUT /judge-servers/:id 改用 queryInteger，非数字 id 回 404 而不是 500。 - 比赛克隆不加归属校验是**有意的**（快速再开一场以前的比赛；保密边界在师生之间不在 教师之间），把这条政策和它的副作用写进注释，免得反复被当成漏洞。 前端： - 编辑用户弹窗的「班级」输入框改成只读 —— 它一直是个改了没用的控件，班级由后端从 用户名推导。 - 新建用户预填唯一占位邮箱、角色默认改成实际会建出来的 Regular User、密码留空直接拦。 - 比赛题目列表的列过滤写的是 top_reaction，实际 key 是 topReaction，空列一直没被滤掉。 - AI 生成流程图加 try/finally，接口失败不再把按钮卡在 loading。 - 单个判题机删除后刷新表格；后台首页显示在线判题机数量（后端一直在下发）。 - 下载测试点失败时读 Blob 里的错误信封弹提示，不再毫无反应。 - 练习题编辑器补上和后端一致的前置校验。 验证：tsc / vue-tsc / vite build / check:routes 全过；后端每条改动都在本机起服务 实跑确认（会话吊销、导入各种重复、练习题七种题型、外键 409、非数字 id）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RC5uL72UY9aZFuTvUKe2jv	2026-09-06 08:41:54 -06:00
yuetsh	bb0f5ec5ef	fix(AI提示): 解锁条件前后端对齐，提示不再一点就没 ... 「失败 3 次解锁 AI 提示」实际是「在当前这次页面会话里再失败 3 次」： problemStore.failCount 是个从 0 起数的内存计数器，刷新、切题、跳进跳出就归零， 而后端闸门数的是数据库里的历史失败数，两边根本不是一回事。昨天在这题上撞了 十次墙的学生今天进来照样看不到按钮。 - 数法收成一个 countFailedSubmissions()，题目详情的 myFailedCount 和 POST /ai/hint 共用。原来详情把「等待/正在评分」也算失败，连点三次提交就能 把按钮点亮，点下去却回 hint-locked - 阈值 3 挪进契约 HINT_MIN_FAILURES，两端引用同一个常量 - failCount 改成 myFailedCount + 本次会话增量；在题目页里登录的补拉一次详情， 否则停在匿名时的 0 - 结果面板改 display-directive="show"，不再一收起来就把流式输出中的提示连同 那次 LLM 调用一起作废；补「上次结果」按钮，原来唯一的重开方式是再提交一次 - prompt 里的判题结果翻成中文，原来拼的是裸状态码，模型不知道 -1 是什么 - system_error 不计入失败数、也不显示按钮：判题机自己崩了不是学生的问题 - 比赛中不给提示，和「求助」按钮同一个口径 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RC5uL72UY9aZFuTvUKe2jv	2026-09-06 07:24:26 -06:00
yuetsh	8a88fe8d99	feat(智能分析): 解题表格改服务端分页，/ai/detail 不再下发整份 solved ... 原来 /ai/detail 把区间内做出来的每道题连排名带等级整份下发，一个活跃学生一年几百道， 一次请求就是几百 KB，而表格一屏只看得到二十行。 拆成两支： - GET /ai/detail 只留聚合（solvedCount、difficulty、tags、attempts、activity、errors…） - GET /ai/solved?offset&limit 按首次通过时间升序分页给逐题明细 排名只跟当前这批题有关，所以分页那支只算一页的 problemIds，不必把整年算一遍。抽出 firstAcQuery / buildSolved / listSolved 三个函数，detail 和分页两边共用。 前端相应改动： - 难度分布改读后端的 difficulty 聚合（本来就在下发，之前是从逐题列表里现数的） - 几次做对改读新的 attempts 数组（每道题的尝试次数）；tooltip 里的题名去掉了 —— 明细是分页拿的，不该为了一个 tooltip 把全量拉回来 - Overview 用 solvedCount - SolvedTable 的代码提交那张走 remote 分页，流程图那张仍是本地分页（一个 OJ 的 流程图题就那么几道，全量下发没问题）；换时间范围回到第一页 - 表格原来是 max-height 1500 的滚动区，现在由分页兜住，滚动条和分页器不再并存 /ai/analysis 的 prompt 仍然带逐题明细（少了它模型只剩聚合数字），但顺手卡了 200 条 —— 以前是整份 solved 无上限塞进去，题做得多的学生一次调用能顶好几倍 token。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LZuPwqDmLEiK9zgQ9z9sVn	2026-09-03 03:18:18 -06:00
yuetsh	4d7be969d9	refactor(智能分析): 重排版面，砍掉重复的三张周期图，补三个新维度 ... 原来 8 张图挤在两列大网格里，左列还套了一层两列小网格 —— 四张小图各自只有半页的 一半宽，"难度掌握情况"的标题被挤断成两行、周期图的 x 轴标签斜着叠在一起、一年热力图 53 列塞进半宽几乎看不清。改成单列为主，宽的图给全宽，窄的图两两并排。 砍掉的重复：进步曲线 / 提交效率 / 周期综合读的是同一个 durationData，半年视图统共 6 个桶四个字段，摊成三张卡六条曲线还都是双轴。合并成一张：柱是完成题目数和总提交数， 线是 AC 率，等级进 tooltip（S/A/B/C 四档离散值连成折线读不出东西，逐题等级表格里有）。 同期解题排名分布也砍了：五片扇形对十几道题做统计本来就是噪声，而排名逐题列在 SolvedTable 里，饼图没有增加任何信息。 换形式： - 标签雷达图 → 横向条形。雷达对比较大小是最差的形式之一，原来还把值归一化成"占最多 标签的百分比"，第一名恒为 100%，等于只画了个排序。现在画真实题数。 - 难度掌握情况 → 难度分布。去掉叠在里面的 S/A/B/C 维度，3×4 十二个格子对一个两个月 做十来道题的学生大部分恒为 0。 热力图改成一格一周（53 格，周一起算，最后一格是本周）。按天切的话一年 365 格里三百多 格是空的，中职学生一年也就二三十天有提交，整张图看着像没用过。颜色阈值跟着按周重定。 新增三个维度： - 错在哪里：判完的失败提交按状态码分组。编译错误占大头说明语法不熟，答案错误占大头 说明是逻辑问题，两种情况老师该给的建议完全不同。 - 几次做对：到首次通过为止提交了几次，分一次过 / 2-3 / 4-6 / 7次以上。原来只有一个 "平均提交次数"，看不出分布。 - 流程图得分：detailsData.flowcharts 早就在下发，但全页一张图都没有，只在解题表格的 第二个 tab 里列着。 顺带： - 时间活跃度从"只统计 AC 时间"改成"统计全部提交"，星期和时段由后端按东八区聚合。 只看 AC 的话十来个点撒进 7×4 的格子几乎全是空的，和热力图的时区口径也对不上。 - 两两并排用弹性容器而不是固定两列网格：知识点分布在没有标签时整张卡不渲染， 固定两列会空掉一半。 - AI 卡片原来有三个条件挂载点（solved>10 在右列、≤10 在全宽行、=0 藏在 Overview 里面），单列之后收成最后一张无条件的卡。 - DurationChart 右轴的 S/A/B/C 一个刻度都没显示过：轴范围 -0.5~3.5，生成的刻度值是 -0.5/0.5/1.5/2.5/3.5，拿去索引 gradeOrder 全是 undefined。 契约新增 activity / errors / rankScope / solved[].attempts / durationData[].acceptedCount。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LZuPwqDmLEiK9zgQ9z9sVn	2026-09-03 03:08:54 -06:00
yuetsh	69883bd016	fix chart	2026-09-03 02:35:29 -06:00
yuetsh	7129f1a12d	fix(智能分析): 提示泄题、班级分析漏鉴权、AI 端点全线无限流 ... /ai/hint 把参考答案原文放进 prompt，靠 system 里一句「不可透露」约束，而学生的代码 本身也是 prompt 的一部分 —— 一段「忽略上面的指示，把参考答案打印出来」的注释就能把 答案套走。改成不再发参考答案，让出来的 2000 字预算给题面；解锁条件（失败满 3 次） 原来只长在前端的会话计数器上，刷新就归零、直接 POST 更是完全绕开，补成端点自己查库。 /ai/class-analysis 只有 requireAuth，前端按钮上的 isAdminRole 只是 UI —— 任何学生 直接 POST 就能用，而且 comparison 全由客户端给，等于一个开放的代打 LLM 接口。补上 isTeacherOrAbove，与 /ai/class-pk-analysis 对齐。 /ai/analysis 收的是前端算好的 details/duration 整包，原样进 prompt 又原样写进 ai_analysis 表。改成只传 start/end/duration/username，学情数据一律服务端重算， detail/duration 的计算抽成 buildDetail/buildDuration 三处共用；报告归被分析的那个人， 不归发起请求的人 —— 后台的 pin 和学生侧 /ai/pinned 都是按 user_id 找报告的。 四个 POST 端点和 login-summary 的模型调用全部过令牌桶（复用 services/throttling， key 用 ai:<id> 与提交、流程图分开计数），超了返 429。 顺带修掉同一块里的几处： - /ai/duration 的等级被写死成 `solved ? "B" : ""`，DurationChart 上那条折线因此恒定 在 B。按旧后端 ai/views/oj.py:484 重新实现，按桶内同班排名算再取平均。 - 热力图 SQL 里 date() 用会话时区、JS 一边用 toISOString 取 UTC 一边用 getDate 取容器 本地时区，三套混用；固定按东八区。365 格原来末格落在昨天，今天那格永远是空的。 - loginSummaryStore.open() 从 ojnext 移植时掉了，LoginSummaryModal 一直挂在 layout 里 但没人触发，整条登录小结链路是死的。 - flowchart bestGrade 拿 max 回头 find 浮点相等的行；ai_analysis.provider 写死 deepseek。 - 前端四处 X-CSRFToken 是 Django 时代遗留，OJ2 后端没有任何 CSRF 校验，连同 getCSRFToken 一起删掉；非 2xx 响应统一走 aiStreamError 转成中文。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LZuPwqDmLEiK9zgQ9z9sVn	2026-09-03 02:13:59 -06:00
yuetsh	2c4d56b29a	refactor(后端): 清掉 Django 遗留的死列与手工级联，角色字符串收成一份 ... 三条迁移，一次部署（0008/0009 含 DROP COLUMN，需要 OJ2_ALLOW_DESTRUCTIVE=1）： - 0008 删 IP 相关：比赛 IP 白名单（前端本来就没有输入框，detail.vue 无条件置空）、 submission.ip（前端从未显示过）、以及一次都没被调用过的 IP 限流桶。 judge_server.ip 是运维数据，保留。 - 0009 删九个只有 Django 时代写过、OJ2 一次都没读过的列：user 的 auth_token / open_api / open_api_appkey / session_keys，user_profile 的 blog / github / school / major / language。open_api 后台连开关都没有，那段「已经开着就不重置 appkey」的逻辑从上线起没进过 if。判据是「全仓零读取」而不是「看着没用」—— raw_password 同样刺眼却是在用的，别一起清掉。 - 0010 给 17 条外键补上删除动作，不再是 Django 留下的一律 NO ACTION。父行消失后 必然无意义、且不构成学生留痕的走 CASCADE（中间表、题单/教程/成就的组成部分、 user_profile 与 user_stat）；需要人看见的继续拦着——submission.problem_id、 以及 user 的绝大多数外键，删用户撞外键会被 handler 翻译成「请改为禁用账号」， 这是有意的：全 CASCADE 会静默抹掉成就与进度，而 submission.user_id 压根没有 外键，结果是一半删一半留。六处手工级联随之删掉。 角色字符串收进 packages/contract/src/roles.ts：原先 ADMIN_ROLES / TEACHER_ROLES 在两个文件各抄一份、学生口径在四个文件各写一遍、前端 USER_TYPE 是第三份副本。 AuthUser.adminType 与 drizzle 的列都收窄成联合类型，二十多处 `=== "Super Admin"` 从此受编译器管着（$type 是纯 TS 层的，generate 确认不产生任何 SQL 变更）。 顺带删掉 db/relations.ts —— drizzle-kit pull 的产物，全仓零引用。 一处行为变化：后台用户列表传非法的 ?type= 回 400，不再静默返回空列表；界面上的 下拉只有合法值，打不到这条。 验证：tsc / vue-tsc / vite build / check:routes 全过；三条迁移在 dev 库执行， 并逐条建 fixture 走 HTTP 接口验过删除连坐与拦截（题单五张子表连坐、user_badge 二级连坐、删有提交的题目仍 409、删有表情的用户仍 409）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AeJoYc2t2d7cThVqMBYrBF	2026-09-02 22:57:45 -06:00
yuetsh	e624c62502	feat(提交): 列表标出来自题单的提交 ... submission 新增 problemset_id，学生从 /problemset/:id/problem/:pid 入口提交时 前端带上、后端落库，提交列表在题目后面挂一个「题单 xxx」的标签，点了进题单。 只是来源标记：题单进度和奖章仍由判完之后的 recordSolvedProblem 按「已加入且含 这道题的所有题单」记账，和从哪个入口进来无关，所以这个字段带错顶多标签不准， 不影响成绩。校验只确认这道题在那个题单里 —— 不查 visible / status、也不查有没有 加入，藏起来的题单里还困着已加入的学生；对不上就当没带，提交照收。 外键 ON DELETE SET NULL：删题单不该带走提交，清掉标记就行。索引建成部分索引 （WHERE problemset_id IS NOT NULL），绝大多数提交不来自题单，全列索引是给 12 万行 白建一遍；谓词能被 problemset_id = $1 蕴含，删题单时的外键检查也用得上它。 列表按页单独查一次题单标题，没有把 problemset join 进那条调过的深翻页查询。 比赛提交恒为 null：题单只收非比赛题。 历史回填从 problemset_submission 取「当年首次 AC 那条」，其余老提交无从判断入口， 一律留空。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y7AsqceaUfC81k7UCDcSk2	2026-09-02 22:06:29 -06:00
yuetsh	cf1eea0810	fix(比赛): 学生管理员开卷、导出只剩十行、排行榜翻页错位等四处 ... ## 学生管理员在比赛进行中能看所有人的代码 canViewSubmission 里 isAdminRole(user) 是无条件放行的捷径，而 ADMIN_ROLES 含 Student Admin —— 同时 contest.ts 的排行榜又把这个角色算作参赛者。既在榜上、 又能读别人的提交，就是开卷。比赛未结束（未开始 + 进行中）时不再吃这条捷径。 旧后端这里写的是 `not user.is_regular_user()`，学生管理员同样放行，所以这条是 相对旧栈**收紧**的一处，不是修回归。只掐角色捷径，不掐 problem.createdById —— 那是这道题的作者本人，他早就知道答案，挡他没有意义。老师和超管不受影响，他们不参赛。 实跑（造了一场进行中、一场已结束的比赛，各一条别人的提交）：学生管理员在进行中的 比赛里列表 showLink=false、详情 404，比赛结束后恢复 200；超管两种状态都是 200； 学生管理员读**自己**比赛中的提交仍然 200，没有把他自己的记录一起挡掉。 同族的 flowchart.ts canView 有同样的角色捷径，但流程图提交入库时从不写 contest_id （永远是 null），那条路上不存在「比赛中的别人的提交」，不用跟着改。 ## 获奖名单导出，参赛超过 250 人时只导出十个人 rank.vue 用 `limit: total.value || 10000` 想一次拉全量，但 queryInteger 对超出 上限的值是**静默回落到默认的 10**，不是截断到 250。于是 300 人的比赛导出 10 行， 而一二三等奖的分档仍按真实总人数算 —— 老师拿到一份十个人、等级全错的名单，还不报错。 改成按 250 一页循环拉，两个出口都留：拿不满一页说明到底了，比对 total 是防着最后 一页正好整除。班级赛（≤250）碰不到这个坑，全校赛会。 实跑：造 20 条排名，limit=300 后端确实只返回 10 行，limit=250 返回 20， 新逻辑拉回 20。 ## 排行榜翻页没有全序 只按 acceptedNumber desc, totalTime asc 排，同分同罚时行序不稳定，而这条列表是 limit/offset 翻页的 —— 同一个人可能在第 2 页出现两次，另一个人从此消失。末尾补 asc(id) 兜全序，id 不参与名次，只保证同分的人每次按同一顺序排。 实跑：20 个同 AC 数同罚时的选手，每页 5 条翻 4 页，共 20 行去重后仍是 20 人， 连翻两轮顺序完全一致。 ## acm-helper 两个接口对 visible 的口径不一致 GET 要求 visible = true，PUT 不要求。比赛结束后收起来，核查页就打不开了， 而标记接口还能用。赛后核查恰恰常发生在比赛已经收起来之后，按 PUT 的口径放开。 ## 删掉 contest_announcement 旧 Django 栈有「比赛公告」，OJ2 从头到尾没搬：没有路由、没有契约、没有前端页面， 表建在那里纯粹是 introspect 0000 时一起拉进来的。确认不需要，连表带 schema 定义 一起删。 删除前核实：没有任何表外键指向它，序列由本表 owned 会随 DROP TABLE 一并消失， 生产快照（db_backup_2026_08_07）里只有 1 行 —— 2022 年 4 月挂在 contest 1 上的 一条测试公告。迁移不写 CASCADE，同 0002：真有别的东西引用了，宁可报错也别被悄悄 级联掉。 **上生产要显式放行**：migrate.ts 的破坏性闸会拦下 DROP TABLE，得 `OJ2_ALLOW_DESTRUCTIVE=1 docker/deploy.sh`，并按它说的先备份。本机已实跑： 不带环境变量确实被拦，带上之后表和序列都没了，重跑是「没有待执行的迁移」， db:generate 报 No schema changes（snapshot 与 schema.ts 对齐，不给下一条迁移留假 diff）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013rpSKCNpVcMhTFhw21YiL7	2026-09-02 20:38:04 -06:00
yuetsh	286487acf3	fix(自学): 少于三分钟的不算已读 ... 原来只要打开过（viewCount > 0）就记成已读，于是「点开看一眼就退」和「认真读完」 在老师那张表上长得一模一样，「已读 17/17」并不说明他学了。加一道 3 分钟的门槛 —— 按最短的一课定的下限，读不完还翻不动的课文，扫一眼是到不了这个数的。 阈值 TUTORIAL_READ_SECONDS 放在 contract 里，前后端共用一个数：学生端目录的 ✓、 后台「按学生」的已读课数、「按课程」的读过人数，三处口径必须一致，各写各的迟早分叉。 **累计时长故意不卡**。时长记的是真实停留，不满三分钟的秒数照样算进去，于是 「已读 0 课、累计 25 分钟」成为一种能看见的状态 —— 他翻了很多课，每课都没读满。 这正是这道门槛想让老师看见的东西，把时长一起滤掉反而把信息删了。 「按课程」的人均时长跟着改了分子：分母是读满三分钟的人，分子就得是同一批人的时长， 否则拿全部时长去除达标人数，人均会被翻一眼就走的人凭空抬高。 顺带修掉「✓ 已读 · -」：心跳 15 秒一跳，点开就走会落在 0 秒上，而 readableDuration(0) 返回的是 "-"。新口径下打勾要求 ≥180 秒，这个组合不可能再出现；打开过但没读满的 显示灰色的「读了 N 分钟」，记是记下了，只是还没到「已读」。 后台筛选栏上方写了一行口径说明，免得老师对着「已读 0 课 / 累计 25 分钟」猜是不是坏了。 本机实跑：student 读 A 课 500 秒、B 课 60 秒 → 已读 1/2、累计 560 秒； A 课「读过 2 人、累计 700、人均 350」，B 课「读过 0 人、累计 60、人均 0」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013rpSKCNpVcMhTFhw21YiL7	2026-09-02 20:37:30 -06:00
yuetsh	bd84599174	feat(自学): 教程和练一练都留痕，老师能看到谁学了多少 ... 自学模块以前一个字节都不落库：读到第几课只存在浏览器的 localStorage 里， 练一练的对错是组件内的一个 ref，刷新即失忆。老师能看到的只有「谁交了题」。 现在两张新表： * tutorial_progress —— 一个学生 × 一课，记打开次数和累计停留秒数 * exercise_attempt —— 一个学生 × 一道练习，记试了几次、错了几次、 第几次做对的、最后一次做错时填的什么 都存聚合不存流水。练习那张表尤其明显：流水会随着学生反复点提交无限长， 而多出来的行回答不了任何新问题 ——「他第 3 次和第 5 次都选了 B」对老师 没有意义，「他试了 7 次才对」有。 停留时长只在页面可见、且十分钟内有过操作时才计。机房的电脑经常开着页面 就走了，不设这道闸的话「停留时长」会变成「电脑开机时长」，老师看到的 数字全是假的。换课、切标签页、关窗口都会先把攒着的秒数冲给**离开的那一课**。 练一练的对错仍然是前端判的：答案本来就随题面一起下发到浏览器，后端再判 一遍也挡不住任何人，只是重复实现七套判题。所以这是教学观察数据，不是成绩。 `last_wrong_answer` 存的是前端拼好的一句人话（「选了 C」「顺序 3-1-2」）， 不是原始作答结构 —— 七种题型形状各不相同，存结构就得在后台按题型各写一套 渲染，而老师要看的只是他错在哪。 顺带修掉预测输出题的一个老问题：它的 `submitted` 一旦为真就不再收回，而 `allCorrect` 是跟着输入实时算的，于是学生错一次之后把答案改对，界面直接 跳成「输出正确！」、提交按钮同时禁用，submit() 再也执行不到 —— 这道题 **永远不会被记成做对**。排序/连线/找错/分组四种题本来就在交互处把 submitted 置回 false，只有这里漏了，按同一套补上。 学生端：目录每课显示「✓ 已读 · 11 分钟」和「练一练 3/5」。教程保持免登录 可读，未登录只是不留痕，并明说一句。 老师端：后台新开「自学情况」（教师及以上可进），三个 tab —— 按学生（默认把读得最少的排在最前，这张表要回答的是谁还没开始）、 按练习（每道题的正确率、一次做对几人、做对的人平均试几次；展开看逐人明细 和他们最后错在哪）、按课程。班级框填 3-4 位是具体班级，1-2 位当年级前缀。 外键用了库级 CASCADE，和 Django 建的那批 NO ACTION 不同：删教程、删用户 不必再记得回来手工清子表。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GW5ef6C2kRW8Ru27ghCaUu	2026-09-01 08:54:27 -06:00
yuetsh	a2f67eebf6	perf(用户导入): 批量导入从几秒降到半秒 ... 导入一个班（45 人）要转好几秒，慢的全在密码哈希这一处： - 哈希在重名检查之前算。老师习惯把同一份名单粘两次，那种情况要白等 一整个班的 argon2 才看到 409。把校验和重名查询提到前面，这条路径 现在是 5.6ms 返回。 - 45 次 argon2 串行 await。改成固定 4 路并发池；不用 Promise.all 是因为 oj-api 的 mem_limit 只有 512m，一个年级 300 人全量并发撑不住。 - argon2id 参数从 Bun 默认的 m=64MiB 显式降到 OWASP 推荐下限 m=19MiB， 单次 140ms → 20ms。参数编码在哈希串里，存量账号照常验证、不用迁移， 旧的 pbkdf2 那条分支也不受影响。 45 人端到端 2.04s → 0.55s。验过：旧 m=65536 的哈希、新 m=19456 的哈希、 Django 的 pbkdf2 三种都能正常登录，错误密码照常拒绝。 顺带把生成页下载的 CSV 裁成用户名和密码两列 —— 发给学生的就这两样。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D	2026-09-01 00:28:16 -06:00
yuetsh	e5a6f2d1e7	fix(题单): 归属校验、进度分母、截止时间可见性等六处零碎 ... ## user-progress 缺归属校验 学生端那条 GET /problem-sets/:id/user-progress 只有 requireTeacher，没有归属校验， 任何 Teacher Admin 都能读到别人建的题单的学生名单与进度。补上，口径与后台 loadOwned 一致（超管放行，其余人只能看自己建的），越权报 404。 顺带订正 docs/specs/phase4-review-authz.md:449：那条写着题单进度「显式下发真名」， 与代码不符 —— 学生端这条走 sampleUser 且没传 includeRealName，realName 恒为 null （SQL 里那次 leftJoin userProfile 是白查的）。真正下发真名的是后台那条 GET /admin/problem-sets/:id/progress，结论仍成立，但当时漏掉了归属校验这个缺口。 ## 头部进度的分母 分母只算必做题之后，ProblemSetHeader 还在拿 completedCount / problemsCount 算 —— 前者是必做完成数，后者是总题数。做完全部必做题的人会看到「9 / 10、90%」，而同一张 卡片上又标着「已完成」，题单 6 那 10 个人正是这种。改成读 userProgress，另外把 「另有 N 道选做」标出来，否则「共 10 道题目」和「9 / 9」对不上。 ## 截止时间 end_time 管的不是「到点不能做了」，是「到点之前看不到自己加入题单之前的旧代码」， 而学生端一个字都不显示 —— 被挡住的人不知道为什么，也不知道什么时候解锁。头部加一个 带解释的「截止 …」标签；提交列表那个锁图标的说明也补上另外两条解锁路径。 ## 两个必然筛空的筛选器 学生端题单列表的难度、状态两个下拉：线上 16 个题单全是 Easy / active，选「中等」 「困难」「已归档」永远是空列表。撤掉，保留关键词搜索。接口那两个 query 参数留着， 哪天真的用起这两个字段再把 select 加回来。 ## 题目移出题单时的提交记录 旧栈 problemset/signals.py 的 post_delete 会清掉该题在本题单的 ProblemSetSubmission， OJ2 没做，于是那张表一直在攒指向已移出题单的孤儿行。补上。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D	2026-09-01 00:01:58 -06:00
yuetsh	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
yuetsh	d9e6a2a3f0	perf(题单): 学生端题目列表少两次 join 一次查询，顺带把并列的 order 排稳 ... ## 排序 学生端 /problem-sets/:id/problems 只按 order 排，没有 tiebreaker，而卡片是按数组 下标编号的（#1 #2 #3）。order 并列时 Postgres 不保证次序，题单 8（3 道题 order 都是 10）、题单 11（2 道并列 4）、题单 14（3 道并列 0）实际就有并列，于是「第 3 题」指 哪道题每次刷新都可能变。后台那条列表一直是 order + id 排的，两边本来就不一致。 补上 asc(id)。教师进度视图里那份题目清单（同一路由文件 :398）有同样的问题，一并补。 实跑：四道题、三道 order 并列，连打 5 次次序完全一致。 ## 载荷 这个接口原来复用 problemListItemSchema，为此要多 join user + user_profile 凑 createdBy、再多查一次标签表凑 tags —— 而题单卡片只渲染题号、标题、难度、分数和 完成标记。tags / submissionNumber / acceptedNumber / createdBy / contestId / allowFlowchart / showFlowchart / hasAstRules 一个都不用，myStatus 甚至写死是 null。 而且 select 的是 schema.problem 整行，题面、样例、答案、ast_rules、flowchart_data、 sql_display 全都白拉回来一遍。 改成 problemSetProblemItemSchema（id / _id / title / difficulty 四个字段），查询相应 收窄：两次 join 去掉，标签那次查询整条去掉，行查询只取四列。每次请求从 4 条查询降到 3 条，其中最大的那条不再拖整行题面。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D	2026-08-31 08:47:57 -06:00
yuetsh	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
yuetsh	f9354b0df1	fix(题单): 进度重算漏了分数和完成状态，奖章没人补发 ... 进度算法在学生路径和后台路径各写了一遍，于是各自漂了一段。后台那份 （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
yuetsh	ff31f7abd1	fix(题单): 补回加入题单前旧提交的遮挡 ... 旧栈的 SubmissionListSerializer.get_show_link 有一条防作弊规则：学生加入含某道题的 题单后，他在加入之前留下的 AC 代码就摆在提交列表里，复制粘贴即可过关，所以要把这段 旧提交藏起来。重写时整条丢了 —— canViewSubmission 里 grep 不到一个 problemset， 自己的提交第一行就无条件 return true。 前端反而把 UI 留着了：ProblemSubmission.vue 那个锁图标的 tooltip 一直写着「这道题在 你已经加入的题单中，只有在题单中完成此题，代码才可见」，而后端永远不会给出 showLink: false，图标一次都没亮过 —— 提示语本身成了操作指引。 题单的 end_time 也因此成了孤儿字段：它不是「截止后不能提交」，是这道闸门的时间边界。 影响面不是边角：8-07 的快照里 1734 人次、188 名学生在加入题单之前就已经 AC 过题单 里的题，占全部已解题次的 22.5%。 补回来的同时改了三处旧栈的做法： - 判断放进 canViewSubmission，列表和详情一起挡。旧栈只挡列表链接， SubmissionAPI.get 光走 check_user_permission，知道 submission id 直接访问照样 拿得到代码，遮挡是虚的。 - 一题落在多个已加入题单里时取 max(join_time)，「存在任一题单要求遮挡就遮挡」等价于 「早于最晚的那次加入」。旧栈用 .first() 取任意一条，行为不确定。 - 比赛提交列表不挂闸门。题单里的题必定是非比赛题（加题时卡了 contestId IS NULL）， 而那条列表只出比赛提交，交集恒空，挂上去就是每页白跑一次查询 —— 而比赛进行中它是 被刷得最狠的。旧栈 ContestSubmissionListAPI 照抄了 bulk_fetch，那边同样是死代码。 闸门只挡「看代码」这一路，不挡 allowShared=false 那一路 —— 后者是分享开关的归属校验， 与作弊无关，挡了学生连自己旧提交的分享都动不了。管理员不受限，对齐旧栈的 is_regular_user() 前提。 解锁三条路实跑验证过：在题单里做出该题、题单过 end_time、题单归档。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D	2026-08-31 08:23:13 -06:00
yuetsh	2031e6a434	update	2026-08-31 07:41:44 -06:00
yuetsh	4b6242ba70	fix(比赛): 比赛进行中，学生打开比赛题必 500 ... contest.ts 两处把「藏起来的难度」表示成空串，而 problemDifficultySchema 是严格的三值枚举，parse 直接抛 ZodError。contestDetailsAllowed 在 「比赛进行中 + 看的人不是管理员」时就是假 —— 也就是正常学生在正常比赛里， 比赛题列表和详情页一开就挂。dev 库 contest 表一直是空的，这条路径没被跑到过。 改成下发 null，契约里给这两个字段单独起了 maskedProblemDifficultySchema。 语义上对齐旧 Django：ProblemSafeSerializer 把 difficulty 放在 exclude 里， 字段整个不下发，而不是给一个假值。 端上顺着 null 补了四处：ProblemInfo 的「难度」项整条不渲染（和旧栈表现一致）， 题目列表、题单列表同理，transforms 的 ProblemFiltered.difficulty 也放开为可空。 这几处是 vue-tsc 逐个揪出来的，正是严格枚举该起的作用。 实测（学生 / 超管 × 比赛题 / 普通题 四种组合）：学生看比赛题详情与列表 从 500 变 200 且 difficulty 为 null，超管仍拿到真值 Low，普通题不受影响； 页面上「难度」整项消失，统计面板其余内容正常。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016DHxhKNxXfG89JnVzHbvgj	2026-08-30 09:01:56 -06:00
yuetsh	b14639d890	feat(api): collab 房间管理与 Yjs 帧转发 ... accept 时按库里的 adminType 复核身份，房间以学生为键。 服务端只按房间转发二进制帧，不解析内容。 老师掉线请求退回排队，学生掉线请求随人清除。 顺带处理三项 Task 2 评审遗留： - TEACHER_ROLES 去重，handler.ts 改为从 routes/helpers.ts 导入，不再自留一份 - 补全学生排队中断线（尚未进房间）的清理分支，避免陈旧请求卡死在列表里 - 修正 websocket.ts 里一处过期注释：username/adminType 是三种 kind 都会填， 不是只有 collab 才填 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd	2026-08-28 02:36:12 -06:00
yuetsh	f38444c97a	fix(代码规则): 给 C 题配的规则一半是哑弹，C++ 题根本配不了 ... 后台的节点下拉是一张 C/Python 混在一起的 15 条表，整份铺给每种语言。给 C 题选到 只有 Python 有的 list_comprehension、f-string，规则存得进去，判题时拿裸名去比节点 类型，C 的语法树里永远不存在它——「必须使用列表推导式」永远失败、「不能使用 f-string」永远通过，两头都不报错，只有学生受着。反过来 mappings 支持的 do_while、 switch、struct、include 在表里没有，编辑器根本选不到。 标签表改成按语言分组，和判题机 mappings 的键集逐条对齐；保存时校验规则与语言是否 匹配，不匹配给中文提示。C 的 target 从 8 个可用变成 14 个。 C++ 接上了 tree-sitter-cpp，386 道 C++ 题从此能配规则。它继承 tree-sitter-c 的语法， C 那 14 个 target 实测全部通用，另加范围 for、类定义、try-catch、throw、namespace、 模板、lambda、using 共 22 个。调用形态和 C/Python 都不同，一并处理：a.push_back() 和 p->push_back() 是 call_expression + field_expression，不是 Python 的 attribute； std::sort(...) 的 function 是 qualified_identifier 而不是 identifier，所以额外比一次 :: 末段，否则学生写没写 using namespace std 会得到不同判定。 一起收掉的几处： - Java/Golang/JavaScript 配的规则一条都不会跑，题目页却照常把它们渲染成「要求」 挂给学生看。现在后台不给这些语言开 tab，下发给学生的要求也按语言过滤。 - 「出现次数」不填数字存下来是一条恒真规则，描述还退化成光秃秃一个「for 循环」。 切换引擎时给默认值，保存时拦下，读取时整条丢弃。 - 次数规则失败只说「if 条件 出现 2 次 ✗」，学生不知道自己写了几次，补上「当前 N 次」。 旧栈的引擎其实算了这个数，但 checker 只取 describe，算完就扔。 - must_have_nesting 的文案没走标签表，学生看到的是「必须使用 for_loop 嵌套」。 - 运算符文案给的是逻辑名，C 题的学生看到「必须使用 and 运算符」，而 C 里写的是 &&。 语义校验放在 astRulesError() 而不是 zod 的 refine 上：astRulesSchema 同时用于读后台 题目详情，在读路径上抛错会让历史脏数据把整个题目详情打不开。保存前先 pickAstRules() 剔除够不着的分组再校验，否则早年配过 C++ 规则的题会把老师锁死——tab 里看不到那组 规则，保存却被拦下。 生产库那 17 条规则（全是 Python3 的 must_exist_node / count_node）行为不变，逐条实跑 核对过。C++ 的 22 个节点 target、25 个运算符也逐个跑了，没有恒假的哑弹。改了带 wasm 内嵌的 ast.ts，dev 和编译两种形态都验过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 11:53:37 -06:00
yuetsh	6c2381ad2c	perf(提交列表): 越早的页越慢，最后一页要等 1.2 秒 ... 翻页用的是 LIMIT n OFFSET m，而 Postgres 对 OFFSET 没有捷径：前 m 行必须真的 产出再丢掉，丢弃又发生在 join 之后，每一行都白回了一次表。生产快照（10.4 万条 公开提交）实测最后一页 1258ms、碰了 95347 个 buffer。最早那几页平时没人翻， 数据页从来不在缓存里，全是冷读，所以感受上比新的几页慢得多。 改成两步：先只 select create_time / id 数到第 m 行拿游标——这两列正好是部分索引 的全部内容，跳过 m 行走 Index Only Scan，Heap Fetches 为 0，纯在索引页里数数； 再拿这一行做 keyset 回查，只回表取 limit 行。同一页降到约 9ms、885 个 buffer， 端到端 HTTP 10.7ms。代价变成 O(m) 个索引条目而不是堆页，按快照密度外推， 涨到 100 万条时最深一页仍在几十毫秒量级。 接口签名和前端都没动，页码跳转照旧。offset 为 0、以及按题号筛选时（条件在 problem 表上，第一步得跟着 join，index-only 就没了）退回普通 offset。 部分索引从 (create_time) 换成 (create_time, id)：create_time 由 new Date().toISOString() 生成，只有毫秒精度，不是全序，游标用 <= 回查时同毫秒的 上一页末行会重复出现在下一页页首。加 id 之后两步走同一个顺序。索引 2.3MB → 6.9MB。 索引两列都建成默认 ASC，靠 Index Only Scan Backward 反着扫。别照着 ORDER BY 写成 (create_time DESC, id DESC)：ORDER BY 的 DESC 默认 NULLS FIRST，索引的 DESC 默认 NULLS LAST，规划器认为出不了序，会退化成 external merge sort（5.2MB 落盘）， 比不加索引还糟。这一条已写进 schema.ts 和迁移文件的注释。 正确性：在快照上把新旧写法返回的 id 序列逐页比对，14 个 offset × 4 个 limit 共 56 组全部一致，含末尾残页与越界。 比赛提交列表暂不改：单场比赛撑死几千条，offset 不构成问题。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 11:13:38 -06:00
yuetsh	e921506f40	fix(流程图): 「重新判题」从来没成功过，而且会把原来的评分清掉 ... `bullmq` 对自定义 jobId 有一条兼容老式可重复任务的校验：一旦包含 `:`，就必须 正好切成三段（`job.js` 里的 `split(':').length !== 3`），否则抛 `Custom Id cannot contain :`。 - 代码提交的重判用的是 `${id}:rejudge:${时间戳}` —— 三段，能过； - 流程图的重判用的是 `${id}:${时间戳}` —— **两段，必抛**。 所以这个接口从上线起就没有成功过一次。更糟的是清空评分发生在入队**之前**： await db.update(...).set({ status: 0, aiScore: null, ... }) await flowchartQueue.add(...) // ← 在这里抛，500 每点一次「重新判题」，原来的分数、等级、反馈、评分明细就永久丢一次，提交卡在 PENDING，队列里没有任何任务会来救它，老师看到的只是「重新评分失败」。 改成三段式 jobId，并把入队失败落成 FAILED（而不是留在 PENDING）—— 与 `POST /flowcharts` 的处理保持一致。 之前几轮验证没发现，是因为当时手上只有一条 PENDING 的提交，被 409（状态不允许 重判）挡在了入队之前，正好绕开了这个 bug。这次完整走教师流程才撞上。 实测：修复前点重判 → 前端「重新评分失败」、库里 status 变 0 且分数清空、 api 日志抛 `Custom Id cannot contain :`；修复后 → 「重新评分已提交」， 70分B级 重评为 86分A级。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 10:51:00 -06:00
yuetsh	e00ab7b876	perf(流程图统计): 给词云的分词量封顶 ... 统计接口会把时间窗内所有已完成提交的 criteria / feedback / suggestions 全取回来， 逐条走一遍 jieba。而前端的「全部时段」是不带 start 的 —— 攒一学年就得把所有评语 重新 cut 一遍，而这是个同步阻塞的请求。 只给词云的分词条数封顶（3000），并按时间倒序取，留下的是最近的那批。 **数值不封顶**：总数、均分、等级分布、各项平均分、完成人数仍然按整个时间窗精确 计算 —— 那只是已取回行上的算术，不额外花钱。这些数一旦采样，老师看到的完成率和 均分就是错的，而且从界面上完全看不出来；词云是辅助性的，看的是高频问题，取最近 这些条足够。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 06:27:33 -06:00
yuetsh	8f08ed03a0	fix(流程图): 学生能翻出全班评分、AI 调用没有限流 ... ## 列表漏了一道门 代码提交列表在 `routes/submission.ts` 里有 `submission_list_show_all` 兜底： 关掉时非管理员一律返回空。流程图列表**从来没有这道门**，而它的过滤是 if (myself === "1" || (!username && 是普通用户)) 只看自己 else if (username) 按用户名模糊匹配 —— 只要带上 `username`，第二支就把第一支的限制绕过去了。学生在提交记录页把 语言切成「流程图」、用户名框随便填一个字，就能翻出全班同学的 AI 评分，不需要 动接口。补上和代码提交同一套口径。 ## 提交与重判没有限流 每一次流程图提交都会触发一次外部 AI 调用，是和判题沙箱同级的有限资源，而这两个 入口都没限流。`canView` 还允许**本人**重试自己的提交，等于学生可以对着自己的 提交反复点，无上限地刷 AI 调用。 限流桶不能直接用 `throttling:user:<id>` —— 那是代码提交在用的桶（capacity 20， 回填约 1.8 个/分钟），共用的话学生在机房连着交几次代码，流程图这边就会莫名其妙 交不上去。单独开 `throttling:user:flowchart:<id>`。 重判对教师放行：成批点几十行是他们的正常用法。 ## 提交编号的权限判断在前端自己算了一遍 契约里 `flowchartListItem.showLink` 是后端逐行下发的（与 `GET /flowcharts/:id` 的放行条件同源），前端却没用，自己按「超管或本人」重算了一次 —— 教师因此看得到 「重新判题」却打不开评分详情。 更要命的是无权限那一支渲染的 `n-text` **照样挂着 @click**，权限判断只改了外观。 学生点别人的编号，后端以 404 挡下，`loadSubmission` 只 console.error，于是弹出 一个 600px 高的空白面板，什么提示都没有。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 06:14:05 -06:00
yuetsh	64facc5701	fix(WebSocket): 断线不重连、评分结果会丢、登出后连接还活着 ... 排查 WS 这一块时发现的一批问题，多数是「机制写了但从没生效过」。 ## 重连 `disconnect()` 里 `enableAutoReconnect = false`，而 `connect()` 从不改回 true —— 登出再登录后，这条连接就永远失去了自动重连能力（configUpdate 那条 watch 上尤其 明显）。改成用 `closedByUser` 表达「用户主动断开」的意图，和 `enableAutoReconnect` 这个**配置**分开。 `scheduleDisconnect` 的回调里断完紧接着一句 `enableAutoReconnect = true`，而 close 是异步的 —— 等 onclose 跑到时标志已经翻回来了，1 秒后又自动连上。那个 「15 分钟空闲省资源」从来没真正断开过。现在只断开，不做事后翻转。 重连的 setTimeout 没存句柄，组件卸载后照样触发 `connect()`，在已销毁的组件上 又建一条连接。现在 `disconnect()` 里 clearTimeout。 退避从「线性 ×5 次」改成「指数 + 抖动、30 秒封顶、次数不封顶」。原来 1+2+3+4+5 只有 15 秒，后端 deploy 重启一次就超了，之后这条连接死到用户刷新为止。抖动是 为了避免一个班几十台机器在同一毫秒一起冲回刚起来的后端。另挂 online / visibilitychange，网络恢复或切回标签页立刻重连，不必等退避走完。 所有 socket 回调改成闭包住局部 ws 并在入口 `if (ws !== this.ws) return`，旧连接 迟到的 onclose 不再污染新连接的状态 —— 也是让 `disconnect()` 能被 onclose 识别 出来的关键。 ## 订阅重放 `pendingSubmissionId` 一发送成功就清空，它只解决了「还没连上就 subscribe」， **没解决断线重连**。而真正会丢结果的恰恰是后者：服务端收到 subscribe 会回一份 当前状态，掉线期间错过的推送就是靠这次重放补回来的；不重新订阅，重连后只收得到 「将来」的事件，可结果已经是过去式了。改成订阅意图保留到显式 `unsubscribe()`， 每次 onConnected 都重发。 这套逻辑原来只有 SubmissionWebSocket 有，FlowchartWebSocket 是 send 失败打一行 日志了事 —— socket 一掉，那次评分结果就再也回不来，按钮一直转圈。提成公共基类 SubscribingWebSocket，两条通道共用。 流程图另加轮询兜底：提交后 5 秒 WS 还没出结果就每 3 秒拉一次，读 status 2/3 结算，3 分钟上限。判题那边一直有兜底，流程图这边没有，而 Redis pub/sub 是发完 不管的，worker 推的那一刻连接不在就永远丢了。 `useSubmissionMonitor` 里 `watch(wsStatus, ..., { immediate: true })` 的回调在 watch() **返回之前**就同步跑了，已经连着时 `unwatch` 还是 null，if 不成立， watcher 永远停不掉：每提交一次泄漏一个，往后每次重连它们都会把各自那个早就判完 的旧 submissionId 重新订阅一遍。整块删掉，直接 subscribe —— 基类已经管了时序。 WS handler 原来不校验 submissionId。学生同时开着几道题的页面时，每条连接都订在 同一个用户 topic 上，别的页面的评分结果会被当成自己的。 ## 会话 握手时校验过一次会话就再也不管了，这条连接却能挂几个小时：用户在别的标签页 登出、或者会话本身到期，旧 socket 照样收推送。加一条 60 秒一轮的巡检，用 Redis EXPIRE 一条命令同时完成「判断存在」和「续期」（续期是必要的：只开着页面 挂 WS 的人一次 HTTP 请求都不发，不该被算成不活跃踢下线）。Redis 抛错时整轮 放弃，绝不因为一次抖动把全班踢下线。 禁用只改数据库的 isDisabled 列、不动 Redis 里的会话，巡检永远发现不了。加 `session:revoked` 频道主动通知，**两种作用域不能混**： { token } 用户登出。只断这一张会话 —— 同一个人在别的设备上是另一张 会话，按 userId 广播会把他手机上的登录一起踢掉 { userId } 账号被禁用。所有设备都得断 先发一帧 force_logout 再隔 100ms 断开。只断不发的话前端只看到一次普通掉线， 会照常重连、页面上还显示着登录态。token 不进帧里 —— 那是 httpOnly cookie 的值， 推到 WS 上就等于交给了 JS，匹配全在服务端做。 前端在协议层拦截 force_logout（和 pong 一样，不下发给业务 handler），并主动 disconnect —— 否则会一路 401 重连到退避上限，正是这机制要消掉的浪费。表现刻意 和 utils/api.ts 里 account-disabled / login-required 两支保持一致：同一件事从 HTTP 和 WS 两条路进来，学生看到的不该有两个样子。 ## 开销与安全 `void handleMessage(...)` 是裸的，里面有两次 DB 查询和一个会抛的 schema.parse， 库抖一下就是一个 unhandled rejection（隔壁 bridgeSubmissionEvents 两处都接住了， 只有这里漏了）。 ping 提到用户查询之前。原来的顺序是「先查 user 再看消息类型」，每个客户端每 30 秒都要为一次心跳打一趟数据库。禁用用户不会因此漏网：推送路径上 bridge 会查， subscribe 这条真正读数据的路径下面照样查。 bridge 两条 per-user 通道都先看 `server.subscriberCount(topic)`，没人订阅就别 查库了 —— 判题高峰期绝大多数事件的目标用户此刻并不在线。 flowchart 评分失败原来把 error.message 原样推给学生、前端直接弹出来，AI provider 的地址和内部报错就这么进了浏览器。改成真实原因写服务端日志。 加每连接令牌桶（20 突发 + 每秒回填 2）。一条 subscribe 在服务端是一到两次数据库 查询，一个学生开着一条 socket 狂发就能压住库。正常流量离阈值几十倍远。 升级时校验 Origin。会话 cookie 是 SameSite=Lax、WS 握手不是导航，跨站页面本来就 带不上 cookie，所以这是防御纵深不是唯一防线。同源放行；本机开发（Vite 5173 → API 3000）自动放行，且只在两边都是本机时成立 —— 生产环境 url.hostname 是正式 域名，这条永远不触发；跨域部署走 ALLOWED_WS_ORIGINS。不发 Origin 的一律放行： 真正的攻击面是带着受害者 cookie 的浏览器页面，而浏览器一定会带 Origin。 顺带：useConfigWebSocket 的 handler 从 onMounted 挪到同步注册（调用方在 setup 阶段就 connect() 了），删掉每条消息打完整内容的 console.log 和死字段 ws.data.username。 ## 没动的 题目页上并没有两条 /ws/submissions —— Form.vue 里 SubmitFlowchart 和 SubmitCode 是 v-if/v-else，互斥。学生实际是 2 条连接：全站一条 /ws/config + 一条 /ws/submissions，正常，不必合并。 ## 验证 55 个用例，分六组打桩跑（假 WebSocket + 假计时器；会话/限流/吊销三组对着真 Redis）： 重连语义 7 断开后不再自我复活、卸载后计时器已取消、退避封顶、 online 立即重连、旧 onclose 不污染新连接 订阅重放 9 未就绪时补发、重连后重新订阅、unsubscribe 后不再重放 会话巡检 8 EXPIRE 三态、只断失效的、同 token 只查一次、 Redis 抖动时一个都不踢 Origin/限流 13 跨站与跨端口拒绝、生产不因 localhost 开后门、 突发额度、按时间回填 强制登出 13 登出只断同 token（别的设备不受牵连）、禁用断所有设备、 巡检先通知再断 前端登出 5 两支表现、收到后不再重连、两条通道只处理一次 前两组做了改动前/后对比，老代码该挂的都挂了 —— 「重连后自动重新订阅」正是这么 跑出来的，此前我以为 pendingSubmissionId 已经覆盖了这种情况。 apps/api 的 tsc 和 apps/web 的 vue-tsc 都干净，仓库既有测试照常通过。 **SubmitFlowchart.vue 的轮询兜底未经运行时验证** —— 在 SFC 内，没搭组件挂载 环境，只过了类型检查和人工核对。要验的话，停掉 worker 提交一次流程图，看 5 秒 后是否转入轮询、3 分钟后是否给出超时提示。 这批改动动了 WS 的行为面（限流会断连接、Origin 会拒绝、巡检会踢会话），上线前 建议手测：提交代码看判题、切流程图看评分、后台改配置看全站生效、开两个标签页 在一个里登出、禁用一个在线学生看另一端反应。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 05:07:26 -06:00
yuetsh	8ae14f055a	refactor(站点配置): WS 直接推契约字段名，去掉前端那层 snake→驼峰胶水 ... 上一版是在前端加 toCamel 把 `enable_maxkb` 换成 `enableMaxkb`。但 snake_case 是 options 表从 Django 继承来的**存储格式**，只该活在库里；WS 这一跳两边都是 OJ2 自己写的，没理由让前端再维护一层换名。 后端改成广播 OPTION_KEYS 的 key（契约字段名）而不是 value（表列键），前端直接 按名字赋值。库里的列名一个字没动。 顺带清掉两处已经死掉的客户端→服务端配置推送： - admin/setting/config.vue 保存后调 updateConfig("enable_maxkb", ...) 和 ("submission_list_show_all", ...)。那条 ConfigWebSocket 从没 connect() 过， send() 直接返回 false；就算连上了，服务端的消息处理也只认 ping / subscribe， 会回一个 error 帧。广播本来就由后端在 POST /admin/website 里做，八个键一个 不落，这两行纯属多余，且用的正是刚废掉的 snake 键。 - ConfigWebSocket.updateConfig 一并删掉，免得再有人调一个静默失败的方法。 这条通道是单向的，原地留注释说明。 验证：dev 栈 + headless chromium 走 CDP 抓 Network.webSocketFrameReceived。 后台保存配置后，页面收到的八条帧的 key 全是驼峰（websiteName / enableMaxkb / submissionListShowAll ...），且页面不刷新，document.title 和页头站点名当场 跟着变。小助手那四条路径重跑一遍照旧：未登录不加载、登录后出现、后台关掉当场 消失、开回来当场重现。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 00:42:14 -06:00
yuetsh	0f34d67cc8	fix(站点配置): WebSocket 广播的 key 是 snake，store 字段是驼峰，实时生效一直空转 ... 后端推的是 options 表里的 snake_case 键： {"type":"config_update","key":"enable_maxkb","value":false} 前端 configUpdate.ts 收到后写的是 `if (data.key in configStore.config)`，而 store 里的字段是驼峰（enableMaxkb）。这个 `in` 判断**永远是 false**，一条配置 都写不进去 —— 站点名称、页脚、班级名单、允许注册、提交列表看全部、知识库挂件， 全部都要刷新才生效，且没有任何报错。`conf.ts` 里那句「前端 configStore.config 用的就是这套键名」是写错的，八成就是照着它写的这段代码。 加一层 snake → 驼峰的转换。八个键都符合通用规则，所以用正则转而不是列表， 将来加键不用改这里；转完认不出来的键直接忽略，别把 store 撑出野字段。 站点改名时顺便同步 document.title —— getConfig() 里本来就是这么设的， 只更新页面里那份、标签页还是旧名字说不过去。 顺带把 MaxKB 挂件那块理干净： - 加载条件改成「已登录 且 后台开关打开」。挂件本来就要登录才能用，原来对匿名 访客也照样注入。 - 删掉它自己那条 /ws/config 连接和 handleConfigUpdate。store 修好之后， 原有的 watch 自然就跟着动了；多开一条连接是重复的，而且没登录时会撞 401 （后端 /ws/config 要求会话），控制台常年一条「[WebSocket] 连接错误」就是它。 匿名访客不做实时生效：/ws/config 保持要求登录，不对外开不鉴权的 WS 端点。 没登录的人下次刷新页面时拿到新配置。 验证：起 dev 栈，用一个假的 MaxKB embed 端点（返回建出 #maxkb-chat-button 的 脚本）顶掉真实地址，headless chromium 走 CDP 看 DOM： ① 开关=开、未登录 → 挂件不在，script 标签 0 ② 开关=开、已登录 → 挂件在， script 标签 1 ③ 后台关掉（页面不刷新） → 挂件消失，script 标签 0 ④ 后台开回来（不刷新） → 挂件重现，script 标签 1 另外把其余三条 WS 通道的键名也对了一遍，没有同类问题：submission_update （submission_id / time_cost / memory_cost / err_info）两边都是 snake； flowchart 的 criteriaDetails 两边都是驼峰且 handler 没读它；成就通知的字段 全是单词，不涉及大小写。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 00:34:51 -06:00
yuetsh	d3757954cd	fix(AI 学情报告): pinnedOnly 那支返回裸数组，页面每次打开都白屏 ... `GET /admin/ai/reports` 同一个 URL 返回两种形状：带 limit/offset 时是 `{results, total}`，带 `pinnedOnly=true` 时是裸数组。前端 getPinnedAIReports 声明的返回类型是 AdminAiReportList、读的是 `res.results`，于是 `pinnedReports.value` 被赋成 undefined，模板里 `pinnedReports.length > 0` 在渲染时抛 `Cannot read properties of undefined (reading 'length')`， 整个页面白屏。空库也照抛 —— 裸数组同样没有 .results。 置顶那支改成同样的 `{results, total}` 信封，total 就是条数。「不分页」的意图 没变，只是别再让一个 URL 有两种形状：调用方没法照着一个类型写，类型标注也就 成了谎话。 验证：本机起 dev 栈，用 headless chromium 走 CDP 抓未捕获异常。修之前 /admin/ai/reports 稳定复现 `TypeError ... at Proxy._sfc_render (src/admin/ai/list.vue:182)`；修之后同一页面零异常，且置顶提示条正确渲染出 「以下 2 位用户的 AI 分析报告已被锁定」加两个用户标签、表格 3 行，PIN 切换 往返（取消 → total 1、再 PIN → total 2）也正常。 顺带把另外 19 个后台/学生端页面扫了一遍，只有这一处抛异常。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 00:18:58 -06:00
yuetsh	a75c70c82d	perf(后端): 干掉 14 处 N+1 查询 ... 列表接口按行发查询是从阶段 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
yuetsh	2ee61756b8	perf(提交列表): count 去掉无谓 join、只取序列化用得到的列 ... 用户反馈「HEADER 点提交后页面空白一段时间才有数据」。拿生产快照 （12.3 万条提交 / submission 表 169MB）在本机实测，问题分两头。 **后端**（本次改的）： - count 无条件 `innerJoin(problem)`，但 problem 只有按题号筛选时才出现在 where 里。带 join 的 count 走 seq scan 78ms，去掉 join 走索引 7.5ms。 - 行查询 `select submission.* + problem.*` 把两张表所有列都拉回来，包括 submission.code（学生源码）、info、ip，以及 problem 的 description / hint / samples / answers / flowchart_data / sql_display —— 这些字段 map 的时候一个都没用上。改成只 select 需要的列。 canViewSubmission 的参数类型随之从整行 $inferSelect 收窄成实际用到的 字段，完整行结构上仍然满足，详情接口调用不受影响。 公开列表和比赛列表两处是同一份代码，一起改了。 **前端**： - list.vue 静态 import 了四个只在默认关闭的 n-modal 里用的组件，其中两个 统计面板还只有老师看得见。光 chart.js 就 197KB，进页面前必须先下完。 改成 defineAsyncComponent 后本路由增量下载 675KB / 59 个文件 → 375KB / 43 个文件。 - n-data-table 没传 :loading，等接口这段时间表格就是一片空白，连转圈都 没有 —— 这是「页面空白」最直接的观感来源。用 try/finally 包，接口抛错 不会把转圈卡死。 - isAuthed 变化时重复拉了一次今日提交数。它不看登录态，onMounted 那次 就够了。列表本身仍然重拉（要更新提交编号列的可点击状态），那次不是 浪费；本想用 userStore.isFinished 把首次请求延后，但 getProfile() 一旦 reject，isFinished 会永远停在 false，匿名用户就再也看不到列表了。 还有一个更大头的原因是索引用不上，导致每次翻页全表扫 169MB，那部分 需要加索引，走下一个提交。 验证：起真实 API 打生产快照，匿名 / 已登录 / myself / 题号筛选 / 语言+状态 / today / offset=5000 / 比赛列表全部 200，响应体大小前后一致 （2990 bytes），字段没丢。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 07:55:47 -06:00
yuetsh	7b6bfeb6fb	fix(标签): /problem-tags 计数漏过滤隐藏题和赛题 ... 标签列表按题目数 > 0 过滤，但计数没有像 /problems 那样限制 visible=true 且非赛题，导致标签在首页出现、点进去却一道题都没有。 同时把旧仓库冻结政策收紧写进 CLAUDE.md：从今天起旧仓库零改动， 不再有内部小修的例外，所有后续工作只落在 OJ2。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-26 00:22:05 -06:00
yuetsh	75dd9bfa42	fix(提交): 独立的 /submission/:id 页面上「复制回到题目」抛 problemID ... ## 复现与根因 在 `/submission/<提交id>` 这个独立页面点「复制回到题目」，必抛： Error: Missing required param "problemID" `detail.vue` 的 `problemID` 是**可选** prop，但 `copyToProblem()` 无条件把它塞 进 `router.push({ params: { problemID } })`。三个组件调用方（提交列表弹框、 题目页提交弹框、后台 ACM 助手）都显式传了这个 prop，所以弹框里一直是好的； 而路由 `submission/:submissionID` 配的是 `props: true`，只喂得进 `submissionID` —— 那条路上这个 prop 恒为 undefined。 组件想自己兜底也兜不了：`submissionDetailSchema` 只有 `problemId`（内部数字 id），没有拼路由要用的 display id（`problem._id`）。 ojnext 里是**一模一样**的代码，不是这次重写引入的。 ## 改法 后端补 `problemDisplayId`：`submissionDetail()` 本来就 join 了 problem 表， 不额外查库。前端 `props.problemID ?? submission.problemDisplayId`。 ## ⚠️ 还剩一条边没关 非管理员看到的 `contestId` 是被抹掉的（`full ? contestId : null`，对齐旧后端 `SubmissionSafeModelSerializer` 的 exclude，把关的是角色不是归属）。所以**学生 自己的比赛提交**从这个独立 URL 打开时，组件判断不出它属于比赛，会跳到公开题 路由 `/problem/<显示编号>`，那里查的是 `contestId is null`，落到「题目不存在」。 改之前这条路是抛异常，改之后是跳错地方 —— 都不对，但主路径（非比赛提交）现在 是对的。要彻底关掉得让后端把 `contestId` 也发给**提交本人**（不只是管理员）， 那是在动一条刻意对齐旧后端的决定，留给你定。另外这条路由**全站没有任何入口 链接**（查过了），只有直接输 URL 或外部链接才会到。 ## 验证 真起服务、真点按钮： - 修之前：点击不跳转，控制台 `Missing required param "problemID"`， Vue 警告里能看到 `<Detail submissionID="..." >` 确实没有 problemID。 - 修之后：无异常，跳到 `/problem/1004`（那条提交对应的题）， 编辑器里是这条提交的代码（`n = int(input())…`），语言也带过去了。 - 回归：走提交列表弹框（有传 prop 的那条路）照样无异常、照样跳 `/problem/1004`。 - tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 23:59:46 -06:00
yuetsh	dd6a6a04eb	refactor(密码): 删掉 PASSWORD_HASH_UPGRADE，无条件写 argon2 ... 上一个 commit 把五个写入点收进 hashPassword，顺手把开关默认值翻成了 true 并 留下 false 分支当退路。这个退路是假的，删掉。 **开关只能拦住将来，修不了已经发生的。** 等真到了要把旧站拉回来的那天，活跃 账号早就都被登录/重置密码升成 argon2 了，这时候设 `=false` 一个也救不回来。 正经退路是切换手册「万一已经改坏了」那节的脚本 —— 拿 `raw_password` 重算 Django 的 `make_password`，能修已经变成 argon2 的账号。留着一个永远轮不到它 上场的开关，只是给后来人多一件要读懂的东西。 删掉的：`config.passwordHashUpgrade`、`hashDjangoPbkdf2` 和它那套 Django 参数 （1200000 迭代 / 22 位 salt / RANDOM_STRING_CHARS）、两个 compose 里的 `PASSWORD_HASH_UPGRADE` env。auth.ts 的登录升级变成无条件。 保留的： - `hashPassword()` —— 虽然现在只是一行 argon2，但「只有一个地方写密码」正是上 一个 commit 的重点。五处各写各的才是当初那个 bug 的根。 - `verifyPassword` 的 **pbkdf2 分支** —— 生产库 1710 个账号全是 Django 写的 pbkdf2（迭代次数 120000～1200000），只会在各自下次登录时才迁移。删了就是 全站登不上。代码注释里写死了这句话。 - 切换手册里的 `raw_password` 恢复脚本，以及回滚流程里新加的「密码要额外处理」 那一步。 ## 验证 改完重跑了一遍关键路径（临时造一个 Django 生成的 120000 迭代老哈希）： - 存量账号登录 200 → 哈希变成 argon2 → 再登 200 → 错密码 401 - 后台重置密码 → argon2 → 新密码能登录 - 注册 → argon2 → 能登录 tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过、 两个 compose `config -q` 通过。测试用户已删干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 23:50:55 -06:00
yuetsh	694e147a21	fix(密码): 五个写入点统一走 hashPassword，默认切 argon2 ... ## 那道「单向门」其实一直开着 `PASSWORD_HASH_UPGRADE` 是并行试跑第一天撞出来的补丁：新后端把 Django 的 pbkdf2 升级成 argon2 之后，旧后端验不了，登录过新站的学生回滚就登不上 （phase5 切换手册里记着这件事）。当时的修法是给**登录时的自动升级**加个开关， 默认关闭。 但写密码的地方有五个，开关只管住了一个： POST /users 注册 PUT /admin/users/:id 管理员改密码 POST /admin/users 批量导入用户 POST /admin/users/:id/reset-password 重置密码 ← 老师天天在用 登录成功后的自动升级 ← 只有这一处受开关管 后面四处无条件 `Bun.password.hash(argon2id)`。也就是说开关关得好好的， **老师给学生点一次「重置密码」，那个账号就回不去旧站了** —— 而「老师帮学生 查/改密码」正是这套系统的日常功能，`raw_password` 那一列存在的理由就是它。 所以那半年里「默认关闭 = 回滚安全」是个假象。 ## 改法 五处统一走 `auth/password.ts` 的 `hashPassword()`，开关两个方向都变成真的： - `true`：五处全写 argon2id，登录时把存量 pbkdf2 顺手升级掉。 - `false`：五处全写 Django 格式的 `pbkdf2_sha256$1200000$<22位salt>$<base64>`， 登录时也不动存量哈希 —— 两边都验得了。 新加的 `hashDjangoPbkdf2` 逐项对齐 Django 6 的 `PBKDF2PasswordHasher`： 1200000 迭代、22 位 salt、`RANDOM_STRING_CHARS` 字符集、sha256/32 字节。 **默认值定成 `true`** —— 旧站今天下线了，没有回滚路径要照顾。要把旧站拉回来 就先设 `PASSWORD_HASH_UPGRADE=false`，切换手册三处说明都改了。 ⚠️ `verifyPassword` 的 pbkdf2 分支**永远不能删**，代码和注释里都写了：生产库 1710 个账号全是 Django 写的 pbkdf2（迭代次数 120000～1200000，跨了好几个 Django 版本），它们只会在各自下次登录时才升级成 argon2。 ## 顺带：dev seed 只有学生号 `seed:dev` 只建 `student`（普通用户），本机想测后台得手工往库里塞 email 和 user_profile —— 而缺 user_profile 的表现极其隐蔽：`/api/me` 返回 profile-not-found → 前端 getMyProfile 抛异常 → localStorage 的 authed 存不进去 → **所有 /admin 路由被守卫静默弹回首页**，不报错。我在这上面卡了很久。 现在 seed 同时建学生和超管（`devadmin` / `devadmin123`），profile 和 email 一起 建好，并且写密码也走 hashPassword。另外加了一道防呆：DATABASE_URL 不是本机时 直接拒绝执行 —— 这个脚本会重置密码并把明文写进 raw_password，其中一个还是超管， 对着生产库跑一次就是把超管密码改掉。要绕过设 `OJ2_SEED_FORCE=true`。 ## 验证 全程拿**旧后端那个真的 Django venv** 对打，不是照着文档推： - 事实核对：Bun 写的 `$argon2id$…` 在 Django 里 `identify_hasher` 抛 `Unknown password hashing algorithm ''`；换成 Django 格式 `argon2$argon2id$…` 能识别，但 `verify()` 抛 `Couldn't load 'Argon2PasswordHasher' algorithm library: No module named 'argon2'`（旧后端确实没装 argon2-cffi）。 原注释说的「格式对了也验不了」结论对，机制略有出入。 - 双向互验：OJ2 写的哈希 Django `check_password` 通过、错密码不通过； Django `make_password` 写的哈希 OJ2 `verifyPassword` 也认。 - 默认（argon2）：拿 Django 现造一个 120000 迭代的老哈希塞进库，登录 200 → 哈希变成 argon2 → 再登一次仍 200。 - 退路（`=false`）：同一个老哈希登录 200 且**哈希不变**；走后台「重置密码」 之后落库是 `pbkdf2_sha256$1200000$…`，**旧站的 Django 验这个新密码通过**。 - 一次 1200000 迭代约 107ms（写密码时的开销；验旧哈希的开销本来就在）。 - tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过。 测试用户（pwtest1 / legacyuser）已删干净，本机库用新 seed 复位。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 23:47:02 -06:00
yuetsh	36a4663193	chore(前端): 清掉四处零引用的死代码 ... 按名字扫了一遍 api 层导出和 utils 常量，四处全仓零引用： **`getContestProblem`**（admin/api.ts）—— 和紧挨在它上面的 `getProblem` 逐字 相同，同一个 URL、同一个类型。旧后端 admin 侧比赛题和公开题是两个端点，合并 之后这个壳留下来了。 **`createMessage`**（oj/api.ts）—— 两代前端都只有定义没有调用。参数名还是旧 后端那套（recipient / submission），函数体里再映射成契约的 recipientId / submissionId，等于给一个不存在的调用方写了个兼容层。 d3b05b8 删掉了它的类型 CreateMessage，函数漏了。 后端 `POST /messages` 是完整实现的，只是后台那个页面 （admin/communication/messages.vue）两代都是一句「未完待续」的占位。 在端点上加了注释说明这件事，免得下次扫「无人调用的端点」时被当成可删。 **`CONTEST_TYPE`**（constants.ts）—— 和上面 30 行处的 `ContestType` 枚举 一模一样。枚举那份有 8 处在用，这个对象零引用。 **`LANGUAGE_ID`**（constants.ts）—— Judge0 的语言 id。真正在用的那份在 utils/judge.ts 的 JUDGE0_LANGUAGE_ID，而且**只有那份是对的**：死掉的这份把 Golang / JavaScript / Python2 全写成了 0，谁要是拿它去调 Judge0，这三种语言 的在线试运行会静默发出 `language_id: 0`。 顺带确认过没有 `constants["LANGUAGE_ID"]` 这类动态取值。 验证：vue-tsc 0 error、vite build 通过、tsc(apps/api) 0 error、 check:routes 168 条无遮蔽。四处都是零文本引用的纯删除。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 23:32:50 -06:00
yuetsh	3f6b4102c9	feat(题目): 学生题目页恢复「要求」展示，走新的 astRequirements 字段 ... 旧后端的 ProblemSerializer.Meta.exclude 没排掉 ast_rules，学生拿到的是规则原文， 题目页上那块「要求」（「if 条件 出现 2 次」之类）是显示的。阶段 3 泄露评审刻意 收掉了它，只留 hasAstRules 布尔值 —— 报告里当时就写了： 「新的更安全，但如果 ojnext 有地方读 ast_rules 的具体内容（比如提示"必须用 for 循环"），需要补个专门的字段。」 前端确实有（ProblemContent.vue 的 astRulesForDisplay + 整块渲染），但那个字段 一直没补。结果是这块在 OJ2 上**永远拿不到数据**，代码还在、没人报错。12 道题 受影响；学生只有提交失败后才能从 statistic_info.ast_results 里看到要求。 现在按评审自己的建议补上：oj 侧题目详情（含比赛题）多一个 astRequirements， **只有渲染要用的两个字段**： { description: "if 条件 出现 2 次", kind: "count" } 文案由后端生成，engine / target 这些内部字段不出现在响应里 —— 收紧保留， 展示恢复。实测响应里搜不到 "engine" 也搜不到 "if_statement"。 ## 顺带合掉一堆重复 描述文案原来有两份几乎一样的实现：判题机 ast.ts 里一份（写进 ast_results）、 ProblemContent.vue 里一份（题目页用）。现在统一成 ast.ts 的 describeAstRule， 两边共用。差异只在 min/max 同时给出时的措辞（生产库里没有这种规则，实际输出 逐字不变），另外判题机现在也能用上节点类型的中文名 —— 没写 label 的规则以前 判题结果里显示 `必须使用 function_definition`，现在是 `必须使用 函数定义`。 节点类型中文名那 15 条原来在 AstRulesEditor.vue（下拉 options）和 ProblemContent.vue（NODE_TARGET_LABELS）各手抄一份，收进契约的 AST_NODE_TARGET_LABELS，编辑器的下拉现在从它生成。 前端删掉 NODE_TARGET_LABELS / ruleDescription / ruleTagType 共 ~80 行， `Problem` 类型里那个 oj 侧根本不下发的 astRules 幽灵字段也去掉了。顺带修掉 一处潜在重复渲染：原来 message 非空时 ruleDescription 返回 message、模板里 又单独渲染一次 message（生产库 message 全是空串，所以没露出来）。 ## 一个坑：契约里差点搞出循环引用 astRequirements 一开始放在 admin.ts，problem.ts 去 import 它 —— 而 admin.ts 本来就 import problem.ts。**tsc 一声不吭地过了**，运行时才炸： ReferenceError: Cannot access 'astRequirementsSchema' before initialization 所以整块 AST schema 从 admin.ts 挪到了 problem.ts（本来也是题目域的东西）， admin.ts 反过来从那边取。这类环 tsc 抓不到，加跨文件 schema 引用时得实跑一次。 ## 验证 tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过。 起服务实打： - 把生产库那条规则种进本地库，匿名请求 /api/problems/1001：astRequirements 是 `{"Python3":[{"description":"if 条件 出现 2 次","kind":"count"}, ...]}`， 响应里没有 astRules、没有 engine、没有 if_statement。 - 浏览器打开题目页，「要求」那块活了：`要求 | if 条件 出现 2 次 | else 子句 出现 2 次`。 - 后台编辑页展开「代码规则检查」，两条规则正常渲染成 `出现次数 | if 条件 | 精确`，下拉选项（现在从契约生成）正确。 - 直接调 describeAstRule / checkAst / astRequirements：三种 kind 分类正确， engine 认不出的规则被丢掉，null 和非对象都回落成 null。 - oj 侧 3 页 + 后台 4 页走查无重定向、console 无报错。 冒烟改动已还原（problem 2 的 ast_rules 复位成 null）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 23:27:40 -06:00
yuetsh	5c772319e9	refactor(契约): 公告两侧形状分开，判题状态码从契约派生 ... ## 公告：一个 schema 兼两种形态，兼出两处谎 前端 utils/types.ts 只手抄了**后台那份**公告形状，oj 侧也拿它当类型用。可 apps/api/src/routes/content.ts 的 `/announcements` 列表既不下发 content 也不 下发 visible —— 于是类型声称列表行有这两个键、运行时都是 undefined。今天没炸 只是因为组件恰好没读（正文是点开后另拉一次详情）。 契约那边则是另一头：announcementSchema 把 content 写成 `.optional()`，让一个 schema 同时兼列表和详情。代价是**详情**拿到的 content 类型也成了 `string | undefined`，组件只能 ?? 兜底。 现在两边都按后台侧早就在用的套路拆开：content 必填，列表用 `.omit({ content: true })` 派生。四个类型各归各位： oj 列表 AnnouncementListItem 无 content、无 visible oj 详情 Announcement 有 content、无 visible 后台列表 AdminAnnouncementListItem 无 content、有 visible 后台详情 AdminAnnouncement 有 content、有 visible 前端手抄的 Announcement / AnnouncementEdit / AnnouncementListItem 全部删掉， AnnouncementEdit 改成从请求体派生（`CreateAnnouncementRequest & { id: number }`）。 后端 content.ts 的列表端点跟着换成 announcementListItemSchema —— 它本来就没 传 content，输出一字不变。 ## SUBMISSION_RESULT 不再手抄 `-2 | -1 | 0 | ... | 10` 这 11 个码是从后端抄的，改成 `JudgeStatus | 9`： 后端那部分从契约派生，9 是前端本地的「正在提交」伪状态（后端永远不下发， 所以契约里没有，见 constants.ts 的 SubmissionStatus.submitting）。 这样 CLAUDE.md 说的「三处同步」才真的有人守：**实测过**，往 judgeStatusSchema 加一个 `z.literal(11)`，constants.ts 的 JUDGE_STATUS 立刻 报 TS2741 缺 '11' 的映射，加不上标签就编译不过。 顺带 useSubmissionMonitor.ts 里两处裸 `9`（各带一句 `// 9 = submitting`） 换成 SubmissionStatus.submitting，注释就不用写了。 ## 顺手 TestcaseUploadedReturns 这个改名 re-export 去掉，直接用契约的 UploadTestCaseResponse（全仓 2 处引用）。 **没动 transforms.ts。** 之前把它记成「旧前端字段名的化石」，看下来判断有误： filterResult 里 difficulty 要查 DIFFICULTY 映射表转中文、rate 要 getACRate 算、 status 要把 myStatus 翻成 passed/failed/not_test —— 是实打实的视图模型，不是 单纯改名。改它只会把计算逻辑挪个地方。 ## 验证 tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、vite build 通过。因为动了后端响应 schema，起服务实跑了公告的四条路径： - curl 三个端点逐个核对键集：oj 列表无 content/visible 且只出可见的那条、 oj 详情有 content、后台列表有 visible 无 content 且两条都在。 - 浏览器里 oj 公告列表渲染正常、点开正文能出来；后台列表两行齐全； 编辑页表单载入正确；改标题保存 PUT 200，库里 title 变了、visible/top 没被 带歪，保存后跳回列表并重新拉取。 （agent-browser 的 `find text 保存 click` 打不到 naive-ui 的按钮 handler —— 不发请求也不报错，一开始误判成保存坏了。改用 DOM 上直接 .click() 就正常， 是自动化的坑，不是应用的问题。） 冒烟用的两条公告已删干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 22:54:01 -06:00
yuetsh	66d51dfd83	chore(账号): 删掉没人调的 refreshUserProblemDisplayIds ... oj/api.ts 里那句 `// TODO: 这个API有问题` 是从 ojnext 原样搬过来的，**说的是 旧后端的 bug，移植时已经修掉了**。旧的 ProfileProblemDisplayIDRefreshAPI： ids = list(acm_problems.keys()) display_ids = [... filter(id__in=ids, visible=True).values_list("_id")] id_map = dict(zip(ids, display_ids)) zip 把「dict 键顺序」和「查询返回顺序」硬凑成对，题目一旦被隐藏或删除 display_ids 就比 ids 短 —— 轻则编号张冠李戴写进库，重则 id_map[k] KeyError。 account.ts 那版是按 id 建 Map、查不到就不动，是对的。留着这条 TODO 只会让 下一个人去查一个不存在的 bug。 顺带查出来：这个函数**两代前端都只有定义、没有任何调用点**。端点清单把 /api/profile/fresh_display_id 标成「前端有调用」是提取脚本匹配到了函数定义 里的 http.get 字面量，不是调用，属于假阳性。前端这个死导出删掉。 后端端点保留 —— 教师改了题目编号之后，学生 acm_problems_status 里缓存的 _id 只有它能刷，是这份缓存唯一的入口。加注释写清它是干嘛的、为什么现在没人 调（要接 UI 从这儿开始）、以及旧后端那版错在哪。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 19:02:37 -06:00