|
|
f6995c841b
|
ops(成就): 加 fix-achievement-hours，订正时区丢失期间误发的「夜猫子」「早起的鸟儿」
OJ2 上线到时区修复之间，成就的小时键按 UTC 判定：UTC 的 0–5 点 / 5–7 点是北京
的上午 9–13 点 / 下午 1–3 点，上课时间的提交被记成熬夜和早起。Django 时代的存量
本来就是东八区口径（已用生产备份做判别性核对），出问题的只有这两周的增量。
脚本按东八区重算两个小时指标（只合并这两个键，不整体覆盖 metrics）→ 撤回不达标
的 → 补发达标却没发的 → 同步 unlock_count → 校正已解锁数与「奖杯收藏家」连锁。
默认只读预演，--apply 落库后自动复核，幂等。
用 db_backup_2026_09_14_18_17_37.sql 实跑：修正 148 行、撤回 60 条（47 + 13，
50 人）、补发 0、连锁 0，其余指标 0 行被动。必须先部署时区修复再跑。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
|
2026-09-14 05:55:27 -06:00 |
|
|
|
4c0c38445c
|
fix(时区): 日历口径收回东八区，读出的时刻统一成 ISO 并保留微秒
旧栈 Django 按 Asia/Shanghai 算日历，OJ2 重写时这个锚点丢了：容器和数据库会话
都是 UTC，于是「今日提交」在北京时间 0–8 点是空的，「凌晨/早起提交次数」整体偏
8 小时，热力图、AC 趋势年份、近两年活跃人数也各按进程时区切。
- 新增 apps/api/src/time.ts 作为唯一锚点（固定 +8 偏移，不依赖进程 TZ / tzdata），
todayStart、成就小时/日期键、热力图、月份平移、年份夹逼全部改走它；
SQL 里按日历切的一律显式 at time zone。
- db/index.ts：连接会话时区设为东八区（兜底）；给 timestamptz(1184) 挂 parser，
读出统一成 ISO 8601 UTC，撤掉为拿 PG 文本形状写的 ::text。parser 保留微秒 ——
生产库 12.3 万条提交几乎全带微秒，截成毫秒会让翻页分界行和班级 AC 排名的
<= min(create_time) 把自己排除（翻页每页丢一条、排名少 1）。
- 前端 parseTime/zonedParts/zonedYear 按 Asia/Shanghai 渲染，n-date-picker 做
toPickerValue/fromPickerValue 平移，站内不再按浏览器时区取时间部件。
- Dockerfile 设 TZ=Asia/Shanghai 作为第二道兜底。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
|
2026-09-14 05:55:17 -06:00 |
|
|
|
91712b482d
|
fix(AST): f-string 规则从上线起就没生效过；加 check:ast 把这类静默错判变成机器检查
Deploy / deploy (push) Has been cancelled
## check:ast
判题机拿 target 的 node 去比 tree-sitter 节点类型，**对不上不报错**：collectNodes 一个
都收不到，于是「必须使用 X」永远失败、「不能使用 X」永远通过，两头不报错，只有学生
受着。上一个提交把两张表合成一张，杜绝了「漏配」，但「配错」照样静默 —— 所以加一个
检查，逐个 target 去问语法：这个节点类型你到底有没有。
bun run --filter '@oj2/api' check:ast
升级 tree-sitter-* 之后必须跑：语法改节点名是常事，后果全静默。它只验节点类型存在，
不验语义对不对（把 while_loop 配成 for_statement 这种两个都存在，机器看不出来）。
## 它抓出来的那个
56 个 target 里坏了一个：Python3 的 f_string 一直配的是 format_string，而这个版本的
tree-sitter-python **根本没有这种节点** —— f-string 是一个 string，靠 string_start 为
f" 和内部的 interpolation 子节点来认。也就是说「不能使用 f-string」这条规则从上线起
就一直判成通过，「必须使用 f-string」一直判成失败。
改成 interpolation。实测：带占位符的 f-string（单双引号都有）命中，而 % 格式化、
.format()、普通字符串、字符串拼接都不误伤。代价是 f"abc" 这种没有占位符的 f-string
认不出来 —— 它确实不含 interpolation，但没占位符的 f-string 本来也没意义，比起原来
「一个都认不出来」是严格的改善。这条写在表里的注释上了。
## 验证
给题目 1004 配「必须有 for 循环 + 不能用 f-string」两条规则实跑：
- 有 for、用了 f-string → 修复前 ACCEPTED(0)，修复后 AST_CHECK_FAILED(10)，
ast_results 为「必须使用 for 循环/通过」「不能使用 f-string/不通过」；
- 有 for、不用 f-string → ACCEPTED(0)；
- check:ast 修复前 exit 1 并指出这一条，修复后 56 个全过、exit 0。
tsc、check:routes、vue-tsc、vite build、单二进制编译均通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH
|
2026-09-10 19:33:19 -06:00 |
|
|
|
ab47e71d6f
|
refactor(契约): 出参不再 parse，后台老题详情和站内信页不再 500
Deploy / deploy (push) Has been cancelled
## 出参改 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 |
|
|
|
b9a80d62bc
|
docs(CLAUDE.md): 合并顶部叠着的更正块，订正前端验证方式，补上契约收紧的边界
## 顶部
两层引用块套着一段「2026-09-10 更正」，说的是同一件事的两个版本（7 张表已删 →
其实还剩一张）。合成一段现状：旧栈不可逆下线、唯一退路是备份恢复、漏网那张
django_migrations 由 0014 补删。考古过程留在迁移文件的注释里，这里不重复。27 行 → 14 行。
## 常用检查
`cd apps/web && bun run build` 后面那句「vite 不做类型检查，构建即验证」是错的：
vite 确实不做类型检查，但**构建也不是验证**。补上 `bun run type-check`，并写明两条
会静默通过的假路子 —— `vue-tsc --noEmit -p tsconfig.json` 检查 0 个文件（那个
tsconfig 是 files: [] + references 的壳，0.2 秒跑完就是信号）、`vite build` 不看类型。
后端也改成 `bun run --filter '@oj2/api' typecheck`（脚本本来就有）。
## 新增「契约收紧要挑地方」
前一个 commit 的教训值得留在这儿：契约 schema 后端也在读路径上 parse，收紧字段
等于给历史数据加闸，对不上要么 500（exerciseSchema）、要么静默塌成 {}（info，
9163/124192 条）。JSONB 原文的形状真相在写入侧，闸就设在那里；要收紧先拿生产备份
跑全量，重点看空值不是键集合。AST 规则的 astRulesError() 本来就是同一个道理。
## apps/web/CLAUDE.md
Commands 段还是 ojnext 时代的 npm start / npm fmt，全部换成 bun 并补上 type-check
的坑。Module Pattern 写的 `views/` 这一层实际不存在（页面组件直接放模块根下），
api.ts 也不按模块分（学生端 oj/api.ts、后台 admin/api.ts、跨端 shared/api.ts）。
工作区根目录的 CLAUDE.md / AGENTS.md 同样折叠了那段更正、订正了类型检查命令
（那两份不在 git 里）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH
|
2026-09-10 04:57:34 -06:00 |
|
|
|
a475cac128
|
fix(数据库): 生产库里还留着一张空的 django_migrations，补一条迁移删掉
Deploy / deploy (push) Has been cancelled
0002_drop_django_leftovers 声称删掉了旧 Django 的 7 张框架表，但生产库实测有 29 张
public 表 = schema.ts 的 28 张 + 一张 0 行的 django_migrations：另外 6 张
（auth_group* / auth_permission / django_content_type / django_dramatiq_task /
django_session）确实都不在了，只有它残留下来。原因已无法从库里复原——0002 的记账行
在，说明当年执行过，而 DROP TABLE IF EXISTS 不会静默跳过它后面的语句。
全仓（二进制、路由、compose、脚本）零处读写这张表，表里 0 行，所以直接删掉。
用 IF EXISTS 让两条既有路径收敛到同一结构：空库自举时 0002 已经删过它（空转），
老生产库还留着（真正动手）。实测两条路径出来的 pg_dump --schema-only 逐字节一致。
「旧栈起不来」这个结论不变——它缺的是 django_session 等表，不是这一张。
迁移会被破坏性迁移闸拦下，这是有意的，放行方式记进了 CLAUDE.md。
|
2026-09-10 04:02:33 -06:00 |
|
|
|
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 |
|
|
|
f38444c97a
|
fix(代码规则): 给 C 题配的规则一半是哑弹，C++ 题根本配不了
Deploy / deploy (push) Has been cancelled
后台的节点下拉是一张 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 |
|
|
|
bb4b5825c3
|
feat(迁移): 0000 改成可执行，空库能自举
0000_crazy_gateway.sql 原本是 drizzle-kit pull 的产物，整份被 /* */ 包着、
可执行语句 0 条，所以任何新库的结构都只能先手工 psql 灌一遍 schema.sql 再打基线。
现在它的内容由 docs/specs/schema.sql（2026-08-07 的生产 pg_dump --schema-only）
机械转换而来：去掉 psql 专有指令 12 条、去掉 7 张 Django 遗留表及其索引外键 41 条，
保留 212 条语句、顺序不动。转换脚本入库在 docs/spikes/。
不含 Django 那 7 张表，是因为 meta/0000_snapshot.json 从来就没有它们（pull 当时
tablesFilter 滤掉了），不建它们才和快照一致；0002 那串 DROP ... IF EXISTS 在新库上
空转、在生产库上真删，两边跑同一串迁移落点相同。
改 0000 对生产库没有影响：migrator 只比 created_at、从不校验 hash，而生产库那行
baseline-0000-faked 早把它挡在门外了。
migrate.ts 配套：空库直接从 0000 建起（并自建 drizzle 记账表——原来这步由 drizzle 的
migrate() 顺手做掉）；自举时不触发破坏性闸门，因为空库上没有数据可丢，拦下来只会逼
每个新环境都带一次 OJ2_ALLOW_DESTRUCTIVE，把这道闸训练成习惯动作。「有表但没基线」
仍然 exit 3。
验证：空库自举出来的结构，和「灌 schema.sql + 打基线 + 跑迁移」这条老路子跑出来的
结构，pg_dump --schema-only 逐字节一致（734 行，零差异）。
转换时踩到两个坑，都写进注释了：注释里不能出现 statement-breakpoint 的字面量
（readMigrationFiles 纯文本切分，会把注释从中间切开）；过滤 Django 对象要看
public.X 形式的对象引用，不能扫语句字样——user 表有一列叫 auth_token。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 09:54:31 -06:00 |
|
|
|
2e871cb5b0
|
refactor(迁移): 换掉 drizzle 的执行器，一条迁移一个事务
drizzle 的 migrate()（pg-core/dialect.js）把所有待执行的迁移塞进同一个
session.transaction()，两个后果：第 3 条失败会把第 1、2 条一起回滚，和 Django
migrate 的逐条提交语义不一样；以及 CREATE INDEX CONCURRENTLY 一律跑不了，
没有任何开关。
现在自己按 journal 逐条执行，一条一个事务。文件第一行写 `-- oj2:no-transaction`
的迁移走裸执行（简单查询协议——扩展协议会把语句包进隐式事务块，CONCURRENTLY
照样被拒），代价是没有回滚，所以这类迁移一个文件只放一条语句。
记账行的写法和 drizzle 完全一致（hash = 整文件 sha256，created_at = journal 的
when），migrator 又只比 created_at、不校验 hash，两套执行器可以互换。
顺带：日志和报错说得出迁移文件名了（readMigrationFiles 不返回 tag，自己读一遍
journal），失败时打印的是 Postgres 那句话而不是 postgres.js 的内部堆栈，
新增退出码 5。
实跑验证（本机 Docker，生产 schema 灌进探针库）：CONCURRENTLY 带标记成功、
indisvalid = t，去掉标记复现 "cannot run inside a transaction block"；
0003 成功 + 0004 失败时，0003 留下、0004 的首条合法语句没留下。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 09:54:01 -06:00 |
|
|
|
eabb61189c
|
fix(数据库): 索引方向被 .op() 吞掉，schema.ts 和真实库对不上
根因不是 .desc()，是 opclass。drizzle-kit 的 CreatePgIndexConvertor 里那个
三元一旦走进 opclass 分支就回不到方向分支，而 pull 给每一列都挂了 .op(...)，
于是"写了 .desc() 却生成不出 DESC"每次都会重演。实测确认：不写 .op() 时
多列混合方向能正常生成，所以原先"多列混合方向的索引别指望 generate"这条
自我限制不成立。
announcement_list_idx 和 contest_create_time_idx 两条真实索引踩在这上面：
生产库里它们带 DESC（schema.sql:1636、:1685），schema.ts 却会生成成全 ASC。
contest_create_time_idx 的 opclass 还串了位（contest_id 标 timestamptz_ops、
create_time 标 int4_ops），那条 SQL 真拿去执行 Postgres 会直接拒绝。
改快照而不是生成迁移：generate 想 drop + recreate，但重建出来的和生产库里
那两条完全等价（DESC 默认就是 NULLS FIRST），执行它只是在 12.3 万行的表上
白挨一次锁。手法和当初处理 problem_tag_name_ci_unique 的 opclass 一致。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 09:53:05 -06:00 |
|
|
|
1f9f33aa3b
|
docs: 0002 迁移已在生产库执行完毕
Deploy / deploy (push) Has been cancelled
`docker exec oj-api oj2-api migrate` 回「没有待执行的迁移」，确认
0002_drop_django_leftovers 已经跑过，7 张 Django 框架表已从生产库删除。
CLAUDE.md 顶部原本写「生产库尚未执行」，切换手册的「回滚保证」写「即将作废」，
两处都过期了。旧栈现在是真的起不来，回滚只剩从备份恢复这一条路，措辞相应改成
既成事实。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 09:18:53 -06:00 |
|
|
|
7793a2fe4c
|
清理旧后端下线后的残留
Deploy / deploy (push) Has been cancelled
旧 Django 后端 2026-08-26 下线、回滚路径作废，代码里还留着几处以它为前提的
死代码和过期注释。
- PUBLIC_WS_URL / PUBLIC_OJ_URL 全部删除。BaseWebSocket 的
`${PUBLIC_WS_URL}/${path}/` fallback 是 Channels 时代的写法，而三个子类
早就各自传 url，等于永不执行；config.vue 里 PUBLIC_OJ_URL 只是个会被
getWebsiteConfig() 立刻覆盖、且指着 :8000 的假初值。WebSocketConfig.path
随之去掉，url 改成必填。
- vite.config：删掉 /api2、/ws2 的迁移期注释，换成还成立的约束（代理这三段
要和 docker/Caddyfile 同步）；newBackend 改名 backend。
- 六处 “回滚时旧后端还要读” 换成真实理由：snake_case 保留的结论不变，但因为
判题机按这套键名写、存量 JSONB 就是这形状。
- CLAUDE.md：数据库一节开头「不写迁移 + 先想清楚回滚」与下一节的 drizzle
migration 自相矛盾，改掉；判题状态码不再要求同步到 OnlineJudge，理由换成
历史 submission.result 和沙箱用的就是这套编码。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 09:09:26 -06:00 |
|
|
|
586c88f629
|
build(数据库): 改用 drizzle migration，加提交列表索引、清掉 Django 残留
Deploy / deploy (push) Has been cancelled
一条线上的三件事：让 drizzle 的迁移机制真正可用 → 用它加索引 → 用它清掉
不再需要的 Django 表，最后接进部署和 CI。
## 1. 让 drizzle-kit generate 可用
原本以为不能用：只加一个索引，generate 却吐出一堆噪音，其中 5 条
`DROP SEQUENCE auth_*/django_*` 打到生产库上会直接搞坏旧后端。
逐个查下来全是 `pull` 出的基线自己不能 round-trip，都是可修的：
- **快照里的 Django 序列**：tablesFilter 只过滤表、不过滤它们的序列。
已从 0000_snapshot.json 清掉。
- **bigint 上限精度**：pull 生成的 `maxValue: 9223372036854775807` 是 JS
number 字面量，round-trip 成 ...776000，每次 generate 都多出 10 条
ALTER COLUMN。改成字符串。
- **表达式索引的 opclass**：problem_tag_name_ci_unique 在快照里带
opclass，drizzle 自己序列化不出来，导致每次 drop + recreate。已去掉。
改完 `generate` 是干净的 no-op。
两个改不掉、只能绕的写进了 CLAUDE.md：索引 `.desc()` 生成 SQL 时会被丢
（单列索引不写方向即可，Postgres 用 Index Scan Backward 服务 ORDER BY
DESC，实测同样 0.08ms）；migrator 把所有语句包一个事务，
CREATE INDEX CONCURRENTLY 跑不了。
最容易吃亏的是 drizzle 没有 --fake-initial：对已有数据的库直接 migrate
会从 0000 跑起、撞表回滚，**而且 exit 1 但一个错误都不打印**。
## 2. 0001 提交列表索引
`WHERE contest_id IS NULL ORDER BY create_time DESC LIMIT n` 用不上现有的
contest_create_time_idx (contest_id, create_time DESC) —— Postgres 不把
`IS NULL` 当成能吃掉首列、从而继承第二列有序性的等值条件。把
enable_seqscan / enable_bitmapscan 全关掉逼它用也不肯，宁可走单列
contest_id 索引再全量排序。于是每翻一页都 Parallel Seq Scan 扫完整张表。
换成部分索引后谓词由索引自己保证，索引序就是查询要的排序序。生产快照
（12.3 万条提交）实测首页取 10 行：61.8ms / 读 18936 blocks →
0.22ms / 读 34 blocks。端到端 94ms → 6ms。
真正要命的不是单次 61ms，是每个请求都要把 169MB 的表刷一遍
shared_buffers —— 一节课几十个学生同时开提交列表，磁盘和缓存直接被打穿。
## 3. 0002 删掉 Django 残留
确认旧 Django 后端不再使用、也不再作为回滚路径。删前核实过：没有任何
OJ2 保留的表引用这 7 张，3 条外键全在它们内部（所以不用 CASCADE，真有
漏网的会报错而不是被悄悄级联掉）；5 个序列都由各自的表 owned，随
DROP TABLE 一并消失；数据全是 Django 自身元数据。tablesFilter 随之移除。
**回滚路径就此作废** —— CLAUDE.md 开头和 runbook 的「回滚保证」「七、回滚」
都改了。这条迁移已在本机 dev 库和生产快照副本上跑通，**生产库尚未执行**。
## 4. migrate 接进部署与 CI
deploy.sh 在构建之后、起栈之前跑 `oj2-api migrate`，失败就中止部署（旧
容器原样还在跑）。CI 走的也是 deploy.sh，所以不用给 GitHub 配数据库凭据，
也不用把生产库对外开放。
迁移文件**不内嵌进二进制**，随镜像装在 /usr/local/share/oj2/migrations。
这样 drizzle 的 migrate() 能原样用 —— 靠 _journal.json 自动发现，新增迁移
不用改任何代码，和 Django 扫 migrations/ 是一回事。内嵌就得为每条迁移
手写一行 import，那是迟早会漏的账。（CLAUDE.md 里「单二进制不能读文件」
那条讲的是 node_modules 和 import.meta.dir 推路径，按显式绝对路径读一个
数据目录不在此列。）
三道闸门，都是写完测出来才补上的：
- **破坏性迁移拦截**：DROP TABLE / DROP COLUMN / DROP SCHEMA /
ALTER COLUMN ... TYPE / TRUNCATE 命中就退出 4，需要
`OJ2_ALLOW_DESTRUCTIVE=1` 显式放行。DROP INDEX / DROP CONSTRAINT 不算，
拦了只会让人习惯性带上放行开关。扫描前先剥注释，避免误报。
- **基线缺失**：退出 3 并直接打印该敲的 SQL。注意判的是
`max(created_at) < 0` 而不是「表不存在」—— 表存在而为空（上次迁移失败
留下的）同样是没基线。
- **迁移目录读不到**：这是最可能犯的错（Dockerfile 漏拷），原本是 drizzle
的堆栈，现在直接说该检查哪一行。
另外发现 0000_crazy_gateway.sql 是 pull 的产物，**整份被 /* */ 包着，
可执行语句 0 条**，所以这个库根本不能靠迁移自举建表。原先写的「空库就从
0000 建」跑起来会炸在一个和真实原因毫不相干的 unterminated /* comment 上。
现在如实说明：结构只能来自 docs/specs/schema.sql 或生产 dump。
验证：镜像内编译（ARTIFACTS=build）出的真实镜像跑完五种场景 —— 拦截、
放行、幂等、无基线、漏拷目录，全部符合预期；dev 形态同样五种场景全过。
tsc / 路由遮蔽 / deploy.sh 语法 / generate no-op 都通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 07:56:30 -06:00 |
|
|
|
7b6bfeb6fb
|
fix(标签): /problem-tags 计数漏过滤隐藏题和赛题
Deploy / deploy (push) Has been cancelled
标签列表按题目数 > 0 过滤，但计数没有像 /problems 那样限制
visible=true 且非赛题，导致标签在首页出现、点进去却一道题都没有。
同时把旧仓库冻结政策收紧写进 CLAUDE.md：从今天起旧仓库零改动，
不再有内部小修的例外，所有后续工作只落在 OJ2。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
2026-08-26 00:22:05 -06:00 |
|
|
|
604857b25e
|
fix(一言): 接回真数据集，之前线上返回的是三条硬编码
/quotes/random 在阶段 3 基线里只铺了个桩（三条写死的句子），读盘逻辑没移植，
所以 oj2.xuyue.cc 上一直是假数据——和 DATA_DIR 无关，哪儿部署都一样。
数据本来就在服务器上、位置也已经对上：旧栈挂 ./data/backend:/data，Django 的
HITOKOTO_DIR 就是它下面的 hitokoto/；OJ2 的 api 挂的是同一个目录。所以
Dockerfile 里跟着 TEST_CASE_DIRECTORY 写死 /data/hitokoto 即可，不用搬文件。
按分类懒加载并常驻，但只留前端用得上的 hitokoto/from 两个字段：原样缓存
7160 条要 2.5MB，裁完 1.4MB，而 api 容器只有 512m。读不到数据集时回落到
内置三条，不影响启动（本机 dev 默认就走这条）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-16 10:20:00 -06:00 |
|
|
|
1a059d0b88
|
feat(切换): 支持并行试跑，新站先挂 oj2.xuyue.cc 跑几天
设计文档写的是「不双跑不灰度」，这次改主意了。理由：「只换前后端」形态下新栈
本来就不碰数据库进程，双跑的增量风险只剩「两个后端同时写同一个库」这一条；
换来的是**正式切换退化成改一行 NPM 上游**，比停机切换更稳，回滚也不用停任何容器。
## 两个新变量
WEB_PORT 对外端口。8080 还被旧 backend 占着（机房是 81）
JUDGE_STATE_DIR 判题机运行状态目录
JUDGE_STATE_DIR 是必须的：不设的话新旧两个 judger 会同时往
`data/judge_server/{run,log}` 里写。默认值用嵌套写法跟着 DATA_DIR 走
（`${JUDGE_STATE_DIR:-${DATA_DIR:-../data}/judge_server}`，compose 支持嵌套默认值，
试过），所以一次性切换那条路径完全不受影响。
test_case 和 public/upload 仍然共享 —— 那是故意的，测试点和题面图片两边必须
看到同一份。
## 手册
新增第四节「并行试跑」，后面章节顺移（原四~九 → 五~十），两处交叉引用一并改了。
第五节拆成两条路径：试跑过的只需改 NPM 上游 + 事后停旧栈；没试跑的走原来那套。
第七节回滚同理。
试跑那节写明了三件容易踩的：NPM 的 Websockets Support 必须打开（漏了的话页面
一切正常，唯独「判题中…」永远不动，而刷新一下结果就出来，自测很难发现）、
两边登录态不互通、以及双写的是真实数据不是沙盒（别在 oj2 上办正式比赛）。
## 验证
试跑形态 `config` 解析：判题机目录落到 judge_server_oj2、端口 8090、test_case
仍指向共享的那份；不设新变量时默认值一个没变（judge_server / 8080）。
四份 compose `config -q` 全通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-16 09:04:16 -06:00 |
|
|
|
cbff292551
|
feat(切换): compose 支持「只换前后端」，接着用旧栈的 postgres/redis
演练把一件事盖住了：当时是把生产 dump 恢复进 `OJ2/data/postgres` 的，
所以没人发现新 compose 在 `OJ2/docker/` 下，`../data` 解析出来是 `OJ2/data`，
而旧栈用的是 `<部署目录>/data`（服务器上是 `/root/OJDeploy/data`）。
照原手册切过去，postgres 会在一个空目录上初始化一个全新的空库 —— 站点起得来，
但没有用户没有题、判题全挂、题面图片 404。旧数据完好，回滚正常，但当天会白吓一场。
## 改法
三组 env 旋钮，默认值保持原样，不影响本机和演练那条路：
DATA_DIR 所有数据卷的根，默认 ../data
DB_HOST/PORT 默认 oj-postgres:5432
REDIS_HOST/PORT 默认 oj-redis:6379
postgres 和 redis 挪进 `profiles: ["local-data"]`，默认不起 —— 否则会跟旧栈
那两个抢 5445 / 5446。配套给 depends_on 加 `required: false`：实测严格的
depends_on 碰上未启用的 profile 会让整个 project 直接 invalid，不是可选项。
代价写进注释了：自带数据形态下 postgres 起不来时 compose 只警告不中止。
给 api / worker 加 host-gateway 映射，DB_HOST 填 host.docker.internal 就行，
不用去猜 docker0 的网段。数据库流量不出本机。
school 那套的 7 个挂载点同样换成 DATA_DIR —— 机房那台也有自己的旧数据目录，
测试点和题面图片都在里面，同一个坑。
## 验证
用 docs/specs/schema.sql 起了个发布在宿主机 5445 的 postgres 冒充旧栈：
正好 4 个容器（没有 postgres/redis）、oj-api healthy、首页与 /api/site
/api/problems 200、未登录进后台 401。读写两个方向都验了 —— 那个库的
pg_stat_activity 里有来自 172.17.0.1 的 postgres.js 连接，judge_server 表里
也出现了新判题机写进去的心跳行。
四份 compose 的 `config -q` 全通过。
手册第三、四、六节按这个形态重写：停旧栈改成只 stop oj-backend / oj-judge
（旧判题机会争 data/judge_server/run，旧 backend 占着 8080），回滚变成把这两个
再 start 起来，数据库进程全程不停。
**DATA_DIR 漏填不会报错**（它有默认值），是切换当天唯一会静默走歪的地方，
手册里给了 `config | grep source:` 的自查和两种症状的区分。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-16 08:57:25 -06:00 |
|
|
|
967e9ef7f7
|
feat: 路由遮蔽检查脚本；切换前把前后端接口逐条对了一遍
## 切换前核对：前端调的接口后端有没有漏
写脚本把前端 224 个调用点和后端注册的路由逐条比对。**零缺口** —— 唯一报出来的
一条是我的正则被嵌套括号截断了（`users/${encodeURIComponent(...)}/badges`），
后端那条路由是有的。「后端有、前端没调」那 25 条也逐个看过，全是脚本的假阳性
（把 `.get("user")` 这类非路由调用当成了路由）和假阴性（前端用三元表达式拼路径，
正则看不见，比如 `GET /me` 其实在 shared/api.ts 里被调）。
结论是没发现缺口，但这个脚本不够可靠、不足以证明"一定没有"，所以没留进仓库。
## 路由遮蔽检查（留成常驻脚本）
比"有没有漏"更值得防的是遮蔽：**Hono 按注册顺序匹配，不是静态优先**。
`/problems/:id` 注册在 `/problems/random` 前面的话，后者永远进不去 ——
不报错、不警告，只是静默走进前一条的 handler。阶段 4 真实发生过一次，
两个教师用的分析端点被吃掉，一直到评审才发现。
全仓 167 条路由按真实注册顺序扫：**零遮蔽**。
这个结论敢下，是因为检测器本身也验了：
- 自检用例里放了阶段 4 那个历史真实案例，能抓到；边界（两边都是参数、
段数不同、不同前缀）不误报
- 核对了 24 个 router 全在扫描范围内，没有漏扫
- 反向验证：往 problem.ts 末尾加一条注册在 `:displayId` 之后的字面量路由，
脚本立刻报出来并 exit 1
未经验证的检测器报"没问题"是没有意义的 —— 这个教训今天已经吃过两次
（tree-sitter 那次、SQL 内存那次）。
脚本落在 apps/api/src/scripts/check-route-shadowing.ts，
`bun run --filter '@oj2/api' check:routes`，加完路由跑一下。
CLAUDE.md 里也写了。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-08 03:42:37 -06:00 |
|
|
|
f6bc42f534
|
docs: 给 OJ2 补一份自己的 CLAUDE.md；Dockerfile 拷上 bunfig.toml
## bunfig.toml 没拷进容器，才是那批「本地能过、容器过不了」的根因
bunfig.toml 里设了 `linker = "hoisted"`，但 Dockerfile 只拷了 package.json 和
bun.lock，于是容器里用的是默认的 isolated 布局（包都在 node_modules/.bun/ 下），
本地靠"提升"才解析得到的包在容器里一律 Could not resolve —— 而本地构建始终是好的，
只有镜像构建才炸。之前是一个一个补直接依赖补过去的（那是对的、该保留），
这里让两边布局一致，是第二道保险。
带上之后装 622 个包（isolated 是 1238），镜像重建通过，二进制在容器里
serve + healthcheck 正常。
顺手补了 main.ts 帮助文本里漏掉的 healthcheck 子命令（compose 里把 command
写错时，看到的就是这行）。
## OJ2/CLAUDE.md
OJ2 是独立仓库，之前没有自己的项目指引。写了一份，重点是几条「不知道就会踩」的：
- **本机 Docker 可用**，整套依赖和上线演练都能在本机跑 —— 别沿用上一代
"本机跑不起来后端"的旧假设
- 单二进制不能依赖 node_modules，`.node` 资源导入 dev 和编译两种形态行为不同，
**改完两种形态都要跑**
- SQL 判题 spawn 的是二进制自己，入口必须有 argv 分发，那道递归闸不能删
- 判题状态码三处同步、raw_password 要保留、比赛只有 ACM、前端要兼容老 Chrome
- 不写迁移：新旧后端跑同一套表结构，这是回滚能成立的前提
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-08 03:37:45 -06:00 |
|
