competition-website

hyzl-agent-backEnd/competition-website

Fork 0

Commit Graph

Author	SHA1	Message	Date
qubiaobiao	31da9580e5	fix(backend): 治理孤儿文件三根因（覆盖前删旧件 / 入库失败回滚 / 清库同步删件）（BACKLOG C9） R45：C8 只清了存量（1003 个 / 9.62 GB），「孤儿为何持续产生」的三条根因仍在，本次一并治理。顺序铁律「先库后盘」：文件删除不可回滚，若先删盘而 DB 写/事务失败 ⇒ DB 指向已删文件 ⇒ 下载 404 = 数据丢失（比留一个孤儿严重）。故全部删除点一律「DB 侧确定成功 → 才删物理文件」。 - app/service/upload.js · saveSubmissionRecord：覆盖前记住旧物理文件路径，existing.update() 成功之后才删旧件（原先 upsert 只改 DB 指向 ⇒ 重传 N 次 = 1 条 DB + N-1 个孤儿） · deleteSubmission：裸 fs.unlinkSync → 复用统一入口 · 新增 removePublicFile(relativePath, label)：唯一删除入口。仅允许 works/ 或 tmp/ 前缀（挡住脏 file_path 指向 templates/、carousel/ 等静态资源被连带删除）+ 拒含 `..` + best-effort 永不抛错，返回 removed\|missing\|skipped（复用 helper.safeCleanup） - app/controller/upload.js · upload() / mergeChunks()：新增 savedFileInfo\|mergedRelPath + recordPersisted 两个标志， catch 里仅当「已落盘 && 未入库」才回滚删除 ⇒ 已入库还删会删掉正被 DB 引用的文件 - app/controller/admin.js · resetTestData：事务内先只读收集六列路径（exam/work/zhongzhi/gaozhi/benke/jiaoshi）， tx.commit() 之后才删物理文件 + 去重 + 上报 orphanFileCandidates/orphanFilesRemoved 验证：verify-c9.mjs 24/24 · verify-c9-reset.mjs 12/12 · verify-c9-rollback.mjs 13/13 check_upload_import_gate.py 14 PASS/0 FAIL · 后端重启（node dev.js）后真实接口联调通过配套：scripts/scan_orphan_files.py（兜底双向扫描，仓库级工具）	2026-09-29 15:06:53 +08:00
qubiaobiao	e8a5b34d42	fix(backend): 补齐单次上传端点的并发护栏（BACKLOG C7） - middleware/concurrency_guard.js: HEAVY_PATTERNS 增加单段上传正则 /^\/api\/upload\/[^/]+$/i —— 单段锚定（[^/]+$）保证不误伤"两段"的轻路由： GET /status、GET /submissions、DELETE /:id（放宽成前缀匹配会让「查状态也 429」） - controller/upload.js: upload() 补 await acquireFileIo() + finally { if (ioAcquired) releaseFileIo(); } ⚠️ 不用 uploadChunk 的无条件 release：本方法 429 分支是 acquire 失败后 return，无条件释放会把"别人的"配额放掉 => 计数下溢 => 护栏静默失效背景：修复前该端点是唯一在用的作品上传路径（Competition.vue:477），却既不在 concurrencyGuard.HEAVY_PATTERNS（表内 chunk/merge 已成死路由）、也不调 file_io_guard => 零护栏。因服务器入带宽仅 ≈1.25MB/s 天然节流，当前风险有限，但按 C3 升入带宽后即变实质风险 => 与 C3 绑定，先补护栏。验证： - verify-guard-r43.mjs 33/33（单元：路径判别力 + 满载 429 + 配额隔离 + 释放语义 + 变异自证） - verify-guard-r43-live.mjs 8/9（真接口：30 路 5MB 并发上传 => 20 成功 / 10 个 429 + Retry-After: 2；15 个轻路由探针在并发中全 200；唯一失败为清理步骤，根因是 saveSubmissionRecord 的 upsert 语义，非缺陷） - 重启后 master PID 23684；[AppBoot][pool] 40 <= 151	2026-09-29 13:17:53 +08:00
WorkBuddy	a303cf2d53	chore: 后端首次基线提交运行必须源码：app/(controller/model/service/middleware/lib/utils/validate/router)、config/、database/(migrations/seeders/sql)、启动脚本、app/public/templates 模板。已忽略运行非必须：node_modules/、logs/、run/、app/public 运行时上传数据、.env*、构建/缓存产物。	2026-08-17 12:25:42 +08:00

Author

SHA1

Message

Date

qubiaobiao

31da9580e5

fix(backend): 治理孤儿文件三根因（覆盖前删旧件 / 入库失败回滚 / 清库同步删件）（BACKLOG C9）

R45：C8 只清了存量（1003 个 / 9.62 GB），「孤儿为何持续产生」的三条根因仍在，本次一并治理。

顺序铁律「先库后盘」：文件删除不可回滚，若先删盘而 DB 写/事务失败 ⇒ DB 指向已删文件
⇒ 下载 404 = 数据丢失（比留一个孤儿严重）。故全部删除点一律「DB 侧确定成功 → 才删物理文件」。

- app/service/upload.js
  · saveSubmissionRecord：覆盖前记住旧物理文件路径，existing.update() 成功之后才删旧件
    （原先 upsert 只改 DB 指向 ⇒ 重传 N 次 = 1 条 DB + N-1 个孤儿）
  · deleteSubmission：裸 fs.unlinkSync → 复用统一入口
  · 新增 removePublicFile(relativePath, label)：唯一删除入口。仅允许 works/ 或 tmp/ 前缀
    （挡住脏 file_path 指向 templates/、carousel/ 等静态资源被连带删除）+ 拒含 `..`
    + best-effort 永不抛错，返回 removed|missing|skipped（复用 helper.safeCleanup）
- app/controller/upload.js
  · upload() / mergeChunks()：新增 savedFileInfo|mergedRelPath + recordPersisted 两个标志，
    catch 里仅当「已落盘 && 未入库」才回滚删除 ⇒ 已入库还删会删掉正被 DB 引用的文件
- app/controller/admin.js
  · resetTestData：事务内先只读收集六列路径（exam/work/zhongzhi/gaozhi/benke/jiaoshi），
    tx.commit() 之后才删物理文件 + 去重 + 上报 orphanFileCandidates/orphanFilesRemoved

验证：verify-c9.mjs 24/24 · verify-c9-reset.mjs 12/12 · verify-c9-rollback.mjs 13/13
      check_upload_import_gate.py 14 PASS/0 FAIL · 后端重启（node dev.js）后真实接口联调通过
配套：scripts/scan_orphan_files.py（兜底双向扫描，仓库级工具）

2026-09-29 15:06:53 +08:00

qubiaobiao

e8a5b34d42

fix(backend): 补齐单次上传端点的并发护栏（BACKLOG C7）

- middleware/concurrency_guard.js: HEAVY_PATTERNS 增加单段上传正则
  /^\/api\/upload\/[^/]+$/i —— 单段锚定（[^/]+$）保证不误伤"两段"的轻路由：
  GET /status、GET /submissions、DELETE /:id（放宽成前缀匹配会让「查状态也 429」）
- controller/upload.js: upload() 补 await acquireFileIo() +
  finally { if (ioAcquired) releaseFileIo(); }
  ⚠️ 不用 uploadChunk 的无条件 release：本方法 429 分支是 acquire 失败后 return，
     无条件释放会把"别人的"配额放掉 => 计数下溢 => 护栏静默失效

背景：修复前该端点是**唯一在用**的作品上传路径（Competition.vue:477），却既不在
      concurrencyGuard.HEAVY_PATTERNS（表内 chunk/merge 已成死路由）、也不调 file_io_guard
      => 零护栏。因服务器入带宽仅 ≈1.25MB/s 天然节流，当前风险有限，但按 C3 升入带宽
      后即变实质风险 => 与 C3 绑定，先补护栏。

验证：
- verify-guard-r43.mjs 33/33（单元：路径判别力 + 满载 429 + 配额隔离 + 释放语义 + 变异自证）
- verify-guard-r43-live.mjs 8/9（真接口：30 路 5MB 并发上传 => 20 成功 / 10 个 429 +
  Retry-After: 2；15 个轻路由探针在并发中全 200；唯一失败为清理步骤，根因是
  saveSubmissionRecord 的 upsert 语义，非缺陷）
- 重启后 master PID 23684；[AppBoot][pool] 40 <= 151

2026-09-29 13:17:53 +08:00

WorkBuddy

a303cf2d53

chore: 后端首次基线提交

运行必须源码：app/(controller/model/service/middleware/lib/utils/validate/router)、config/、database/(migrations/seeders/sql)、启动脚本、app/public/templates 模板。
已忽略运行非必须：node_modules/、logs/、run/、app/public 运行时上传数据、.env*、构建/缓存产物。

2026-08-17 12:25:42 +08:00

3 Commits