|
|
ed56a209ea
|
chore(格式): Prettier 统一到全仓，后端和契约一次性格式化
Deploy / deploy (push) Has been cancelled
原来只有 `apps/web` 在 Prettier 下（配置在 `apps/web/.prettierrc.toml`、脚本在
web 的 package.json），后端和契约从来没格式化过 —— 手写在 100 列上下，`db/schema.ts`
还是 drizzle-kit pull 留下的 tab 缩进。两套口径分叉久了，跨端改一处就得记着「这边
什么风格」。
- 配置搬到根目录 `.prettierrc.toml`，内容不变（`semi=false`，其余全默认，
printWidth 80 —— 和前端已有的格式一致，不另立一套宽度）；
- 脚本统一成根目录 `bun run fmt`，覆盖 `apps/*/src`、`apps/web/tests` 和两个构建
配置；web 自己那份 `fmt` 和重复的 prettier 依赖删掉；
- `.prettierignore` 挡掉两类不该碰的：drizzle-kit 生成的 `src/db/meta/` 结构快照
（它是 db:generate 的比对输入，只该由 drizzle-kit 写）、unplugin 每次 dev 都会
重写的 `auto-imports.d.ts` / `components.d.ts`；
- 全量跑了一遍。纯格式，无行为改动：api typecheck / check:routes / check:ast、
前端 type-check 全过，起 api 打了接口确认正常。前端这 39 个文件的小改动是
prettier 版本漂移（类型断言的换行口径变了），不是新配置带来的。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-16 08:27:34 -06:00 |
|
|
|
a5b57d8ab8
|
fix(判题): 任务被遗弃时给提交落一个终态，别永远停在「等待评分」
judgeSubmission 自己的 try/catch 已经把正常路径上的异常都接住、落成 SYSTEM_ERROR
了，但队列的 failed 事件只有一行 console.error。判题队列没配 attempts（flowchart
队列配了 3），失败即终局；worker 进程被杀那种 —— 机房断电、容器 OOM、部署重启 ——
BullMQ 走完 stalled 重入队还是没人接，最后 emit failed，那条提交就永远停在
「等待评分」：学生看着转圈，教师统计里还占着一个「判题中」的名额。
加 failAbandonedSubmission()，在 failed 里调用，复用已有的 markSystemError（只动
PENDING/JUDGING，判完的和重判过的都不会被覆盖）。三种情况实跑验过：不存在的提交
安全返回、卡住的那条变成 result=5 并写入 err_info、已 AC 的那条没被动。
生产库里 3 条卡死的 PENDING（2022-11 / 2026-03 / 2026-04）都是旧栈时代留下的，
OJ2 上没有实例 —— 这次是把口子堵上，不是修已发生的故障。那 3 行和跟着差 1 的三道题
计数器还得手工处理。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd
|
2026-09-08 18:29:30 -06:00 |
|
|
|
c27c9fdbf9
|
fix(流程图评分): 队列重试从没生效过、AI 调用不设超时、等级由模型自报
## 重试是摆设
`flowchartQueue` 配了 `attempts: 3` + 指数退避，但任务开头有一道守卫：
if (!row || ![0, 1].includes(row.flowchart.status)) return
而 catch 里第一件事就是把 status 写成 3(FAILED)。于是第 2、3 次尝试进来一看
状态是 3，直接 return、算作成功 —— **实际只跑了一次**。AI 侧的偶发失败（限流、
超时、网络抖动）永远等不到重试，学生看到「评分失败」只能自己重新提交。
改成只有最后一次尝试才落 FAILED，中间几次把状态留在 PROCESSING(1) 让守卫放行。
「是不是最后一次」由 worker 算好传进来：`attemptsMade` 是「此前已失败几次」，
当前这次还没计入，所以判据是 `attemptsMade + 1 >= attempts`。
实测（用没配 AI_KEY 这条必然失败的路径）：修复前 t+1s 就落 FAILED、只评一次；
修复后评满 3 次，状态到 t+7s 才落 FAILED。
## fetch 不设超时
`completeChat` 直接 `fetch`，而 fetch 默认不超时。AI 侧一挂就把 worker 的并发位
（只有 2 个）一直占着，学生那边的按钮也就一直转。加 60 秒超时。
流式调用**不加**：那边超时会把正在推的长回答直接掐断，而客户端断开本来就能收尾。
## 等级不该由模型说了算
提示词里写死了 S/A/B/C 四档分数区间，但模型偶尔会给出「88 分配 S 级」这种自相
矛盾的结果，甚至直接吐「优秀」。脏值会一路串到等级分布图、等级筛选，以及
「A/S 才把流程图展示给学生」的判断里。改成一律由分数推出等级，模型自报的 grade
不再采信；score 本来就已经 clamp 到 0-100。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-27 06:14:21 -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 |
|
|
|
ec274419c3
|
Build Phase 2 judge vertical slice
|
2026-08-06 22:42:39 -06:00 |
|
