|
|
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 |
|
|
|
cf1eea0810
|
fix(比赛): 学生管理员开卷、导出只剩十行、排行榜翻页错位等四处
Deploy / deploy (push) Has been cancelled
## 学生管理员在比赛进行中能看所有人的代码
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
3f6b4102c9
|
feat(题目): 学生题目页恢复「要求」展示，走新的 astRequirements 字段
Deploy / deploy (push) Has been cancelled
旧后端的 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 |
|
|
|
20ecc05f63
|
fix(Minor M2): 比赛权限加中间件兜底
旧后端用 @check_contest_permission 装饰器，漏挂一眼看得出来；新后端手工在 handler
里调 canAccessContest，漏调一次就是静默放行，而且这类路由挂的是 optionalAuth
（本身不拦人），从路由注册那一行完全看不出它受保护。
新增 requireContestAccess(checkType, paramName)，把「取比赛 → 404 → 鉴权 →
401/403」四步收进注册行。手工调用点 5 → 2：
- GET /contests/:id/access —— 报告权限而非强制，不能 403，留手工
- POST /submissions —— 比赛 id 来自请求体，中间件跑时 body 还没解析，留手工
两处都就地写了说明。canAccessContest 改成泛型，因为 Hono 的 Context 在
Variables 上逆变，写死 Context<AppEnv> 与 ContestEnv 不兼容。
实测拦截行为不变：匿名 401、登录 200、密码赛未过密码 403。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 07:00:58 -06:00 |
|
|
|
b4b61af6b0
|
fix(阶段3): 匿名不可读用户档案，真名改为默认不下发
F1：GET /profiles/:username 只挂了 optionalAuth、handler 内无登录判断，
匿名可读 email、adminType、className、lastLogin。用户名又能经 /rankings/users
公开枚举，等于可以无 cookie 批量收集全校学生的邮箱与最后登录时间。
handler 开头补上未登录即返回空，对齐旧后端 account/views/oj.py 的
UserProfileAPI.get 首行 `if not user.is_authenticated: return self.success()`。
F2：旧后端把「是否下发真名」做成 UsernameSerializer(need_real_name=False)
的默认关闭开关，全仓 11 处调用只有比赛榜单一处显式打开；新后端没搬这一层，
真名随用户对象无条件下发，13 个下发点里 8 个匿名可达。
这里补回同一层：helpers.ts 新增 sampleUser()，realName 默认不下发，
需要的地方显式传 { includeRealName: true }。12 个下发点改为走这个函数，
只有比赛榜单一处打开（对齐 contest/serializers.py:84 的 is_contest_admin）。
没有逐处删字段 —— 那样下次新增端点还会重犯。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 01:59:05 -06:00 |
|
|
|
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 |
|
