7 Commits

Include renames

Author	SHA1	Message	Date
xuyueandClaude Opus 5.5	37e971b6b4	refactor(判题机): 换成 go-judge，空闲内存从几百 MB 降到 16 MB ... 原来的 JudgeServer 按核数起 gunicorn worker、每份提交再按核数开进程池，空闲内存跟着核数走 （2 核 52MB、16 核 305MB）。换成 go-judge 后空闲 16MB，同一批提交判题中 80–100MB（原来约 370MB）。 go-judge 只管在沙箱里跑命令，编译、逐点运行、比对输出、定状态码搬到 judge/sandbox.ts， 口径逐条照搬 JudgeServer，出参形状不变。拿生产库真实提交新旧逐点对比：C 2000 份 1989 一致、 C++ 891 份 890 一致、Python 2000 份全一致；不一致的是 system("pause")（现在不再判运行时错误）、 未定义行为、endl 死循环打印（运行时错误变运行超时），见 docker/judge/README.md。 - 判题容器改成 privileged（go-judge 要自己建 cgroup），镜像 oj2-judge-3 - 心跳改由 worker 每 5 秒问判题机 /version 代记，删掉 /api/judge-server/heartbeat - 前端统一用 stripJudgePath 去掉判题机工作目录（新的 /w/ 和旧的 /judger/run/） - 提交前编译检查只编译不运行 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-26 15:03:57 +08:00
xuyueandClaude Opus 5.5	adea781b8e	fix(一言): 句子下面多挂了个「· 游戏」「· 动画」的分类，看着啰嗦——不显示分类；本机不用再配 env 就能读到一言数据集 ... - 出处只写「—— 谁《出处》」。接口里的分类还在，只用来判断出处要不要加书名号 - HITOKOTO_DIRECTORY 默认值改成仓库旁边的 ../sentences-bundle，.env.example 里那几行撤掉。 线上不受影响：镜像里 Dockerfile 写死了 /data/hitokoto Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 15:14:03 +08:00
xuyueandClaude Opus 5.5	c7a8e05385	feat(一言): 一言挤在角落里，出处被截成「来自 Structure and Interpretatio…」、不知道点一下能换——改成引号 + 句子 + 「—— 谁《出处》· 分类」+ 换一句按钮 ... 设计稿「一言重设计」A 版： - 句子一行，长句（数据集 p90 44 字、最长 255 字）截断，点句子弹出全文 - 出处写成「雷电将军《原神》· 游戏」：接口多下发 fromWho 和分类名，「佚名」「网络」这类充数的出处不写 - 「换一句」是个看得见的圆按钮，换的时候转一圈 - 契约 quoteSchema 从 string | Record 收成定形对象 - .env.example 说明本机怎么把 HITOKOTO_DIRECTORY 指到 sentences-bundle（不指就一直是内置的三句） Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 14:19:55 +08:00
xuyueandClaude Opus 5.5	eb32676de4	feat(题目): 「运行例子」「自己输入」改用和提交同一台判题机——例子上跑出什么样，提交在这几个例子上就是什么样 ... 原来试运行走另一台 Judge0：C 是 GCC 9、编译参数也不一样，Python 的语法错误回来的是运行错误， 没有题目的时间内存限制和代码模板，例子上的结果常和提交对不上。现在走本站判题机 （POST /trial-runs），同一套编译命令、这道题的限制和模板，对不对也由判题机比。 - 不落库、不算提交、不进判题队列：api 进程里自己排队，全站同时 TRIAL_CONCURRENCY 批 （服务器 2、机房 4），每人最多两批，排满或等超过 30 秒就请学生过一会儿再点 - 死循环不停打印时判题机回包会很大，超过 16MB 就掐断，告诉学生输出太多、停不下来 - Python 语法错误用和提交一样的说明：第几行、中文标点标红、一键换成英文 - 运行时错误和提交用同一个解析，说清楚第几行、为什么（下标越界、int() 转换失败、段错误……）； 比赛里照旧只给按结果码的那一句 - 语法没过、服务没跑成时，标题不再说「N 个例子没对上」 - 后台「生成测试点」一并迁过来，编译警告不会再写进 .out；Judge0 的地址和调用全部删掉 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-29 08:09:44 +08:00
xuyueandClaude Opus 5	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
xuyueandClaude Opus 5	b7adf2993d	fix(阶段3): 去掉判题机 token 的弱默认值 ... F5：token 校验实现本身是对的（用了 timingSafeEqual），问题是缺省值 "oj2-dev-token" 写死在仓库里 —— 写死在仓库里的 token 等于没有 token。 后端改为对齐旧后端 options/options.py:93 的 fail-safe： env 缺失时生成随机值并在启动日志里告警，判题机连不上，但不会静默用弱默认值。 compose 改为 ${OJ2_JUDGE_TOKEN:?...}，未设置直接报错退出。 本地开发怎么设写在 docker/compose.dev.yml 顶部与 .env.example 里： 两个变量名不同（判题机镜像认 TOKEN，后端认 JUDGE_SERVER_TOKEN）但值必须相同。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 01:59:27 -06:00
xuyue	ec274419c3	Build Phase 2 judge vertical slice	2026-08-06 22:42:39 -06:00