 AskaEth
|
53a0cb225c
|
feat: 备份恢复 / 图片清理 / 单位恢复 / 审计过滤 / 模板引擎 M1 + 两个导入缺陷修复
用户点名的三件事（模板功能、删死代码、剩余缺口）这一批全部落地，另修掉两个刚暴露的导入缺陷：
**新增能力**
- 备份恢复：`POST /api/backup/restore`（admin）。先把校验做在拍快照之前（只读打开 + integrity_check +
关键表校验 + 异类库标志表互斥），再用 VACUUM INTO 拍「恢复前安全副本」，然后关连接、整文件替换、
触发优雅重启；`-wal` 还在时直接拒绝（宁可失败也不让旧库 WAL 套到新库上）；恢复后审计直写"恢复之后
还在的那份库"（不走通用 Auditor，否则记录只会落在被替换掉的旧文件上）。顺带修掉：裸服务端连续恢复
第二次会在拍副本处崩出一句看不懂的 500，现在回 503「上次恢复后尚未重启，请先重启服务端」。
- 安全副本保留策略：每类库保留最近 5 份，独立于 .db 的 20 份滚动清理。
- 图片管理：`DELETE /api/uploads/{name}`（被引用 409 并列出引用点）、`GET /api/uploads/orphans`、
`POST /api/uploads/orphans/delete`（只删列出的孤儿，宁漏勿误），全部 admin（与字体删除同档）；
`deploy/backup.bat` 补上 uploads/ 归档（logs 不归档：可再生的诊断且会无上限增长）。
- 已彻底删除单位的恢复：`POST /api/teams/{id}/restore`（与 hideTeam 同档）。幂等；恢复不会把「停用」
变成「启用」；真机确认恢复前后榜单逐字节一致、change_log 最大值不变（数据一行没动，不需要重算）。
界面加「显示已彻底删除的单位」（仅 admin）与恢复按钮；非 admin 的删除确认框里写明"本账号无法自行恢复"。
- 审计日志按 `action` 过滤（子串模糊，输入里的 %/_/\ 转义成字面量）。
- 删除死表 recent_projects（新增 system 迁移 0006，未动已应用的迁移）。
- points_override 不再"设了没效果"：写入侧 400 + 引擎侧守卫，提示改用「积分调整」。
- 联队份额空壳清理（UnionAttribution/UnionSplit/Entry.TeamShares/resolvedShares 等；TeamShare 类型保留，
因为 export/realtime/奖牌流水三处在生产路径上构造它）。
- 自定义大屏模板 M1：插值引擎（parseTemplate/renderTemplate），任何情况都不抛异常、未定义→空串+警告、
警告按 (code,path) 合并计数、无 eval/innerHTML，57 个新用例。
**两个真缺陷（前两个已随 0.1.6 出包）**
- 基础数据包导入「排序」列口径不一致：小项/组别留空保持原值，单位/大项留空被写成 0（plan 没从库里
现值起手）→ 四张表统一为「留空保持原值」。
- 同类第二处：布尔列「整列被删掉」被当成"取默认值"，会把库里所有停用的单位/大项静默改回启用 →
改为「缺列 = 不动」（写侧与解析侧都收口，补了"缺列保持/空格子=是/显式否=停用"三组对照用例）。
**删死代码**
- createEntry / updateEntry / deleteEntry / entryEventID / checkCategoryInEvent / getEntry /
normalizeEntryStatus / ExportBaseDataXLSX（全仓 grep 零引用）。⚠️ 随之记入文档：「组别必须属于该小项」
这道校验现在只由导入路径"按小项+组别名解析"天然保证，将来若新增从请求体接收 categoryId 的接口，
必须自己补校验（库层没有复合外键）。
**文档**
- devdocs 全面同步（01/02/03/04/05/06/07/09/11/12/13/README；含身份口径、延迟结算、大屏单栏新版式、
新增路由与设置键、R18/R19 风险）；docs 复核 + 第二轮（身份口径三个易写反的分支、图片删除、备份覆盖、
审计过滤、单位恢复、去掉硬编码版本号、上线检查清单 +5 项）；debug/使用说明 6 份逐份 diff 一致。
测试：服务端 13 包（连跑两遍）、前端 406 例、Console 28 例 + 18 文件语法检查 —— 全绿。
版本号 dev_0.1.6 → dev_0.1.7。
|
2026-09-11 19:26:36 +08:00 |
|
|
AskaEth
|
2c983bcfdf
|
fix: 枚举入参校验(500→400)、5xx 错误串不再外泄、健康检查探库、限流键清理
服务端一批「会误导现场」的缺陷，全部补了测试：
- 枚举型入参（events 的 event_type/result_mode/result_type/compare/status、
scoring_profiles 的 tie_mode/record_bonus_mode、entries.status、results.status）
过去完全没有校验，非法值一路落到 SQLite 的 CHECK 约束，被统一错误处理当成
服务端异常报成 500；现在统一在 enums.go 拦成 400 VALIDATION_FAILED，
message 带字段名与合法取值、detail 带原始输入值。空值仍走原来的默认值。
- 5xx 响应体不再回显内部错误原文：新增 apiError.logDetail，SQLite / 引擎的
原始错误串只进 ERROR 日志的 detail 字段。此前正好是反的——前端拿得到原文，
日志里只有「服务端异常」。同时校准 newAPIError / internalMsg 的 skip 层数，
拦截点不再退化成 response.go 里的构造函数。
- /api/health 新增 db / dbError：用 SELECT 1 探库（Ping 探不到「文件在、库读不动」），
超时 5s 与 busy_timeout 同量级。状态码仍恒 200 —— Console 拿状态码当存活信号，
数据库故障时回 5xx 只会变成重启循环，两个事实分两个字段表达。
- 修改密码时原密码错误由 401 改为 400 AUTH_FAILED（新增 wrongCredential）：
401 的语义是「本请求没有有效会话」，而这里会话是好的。
- 限流 hits map 在键数超过阈值时清理窗口内已无记录的键（窗口内活跃的键不动，
否则堆键数就能冲掉别人的计数）。
- createEntry / updateEntry 拒绝「A 小项的报名挂在 B 小项的组别上」。
数据库层仍无 (event_id, category_id) 复合外键（重建 entries 会牵动 results /
score_ledger 的级联，风险高不做），这一层先兜住。
- 补测试：枚举字段逐项正反例、CSRF 反向用例、写限流 429、健康探库（含库故障）、
5xx 不外泄原文、限流键清理不误删。
|
2026-09-11 14:28:25 +08:00 |
|