fix(release): daily backups no longer replace the recovery point
Product chose to keep the scheduled backup, but the current recovery point must stay the one created by hand. Daily runs still encrypt and restore-verify, then record a separate latest-backup note. Co-Authored-By: Grok (agent loop)
This commit is contained in:
jesse-ux
co-authored by
Grok (agent loop)
Grok (agent loop)
parent
6ba63470a9
commit
5c0d895391
@@ -0,0 +1,34 @@
|
||||
# 进度 · 内测安全网修复（2026-10-15）
|
||||
|
||||
- 分支：`codex/beta-safety-net-20261014`
|
||||
- 任务书：`docs/tasks/TASK-beta-safety-net-fix-20261015.md`
|
||||
- 上一轮已推送：`53d8df257ddef8918034acef36df0b4b7daade2c`
|
||||
- 产品选 A：每天的自动备份照做，但不改当前恢复点。
|
||||
|
||||
## 做了什么
|
||||
|
||||
- 先合并最新 `origin/staging`，没有改写已经推送的提交。合并时本分支的 BUG-1354 和更早的答题强度记录撞号，安全网三条顺延为 BUG-1355、BUG-1356、BUG-1357。这次的修复是 BUG-1358。
|
||||
- 用已经存在的 `RECOVERY_BASENAME_PREFIX=production-daily` 当开关，没有另加模式参数。这个前缀下，脚本仍完成导出、加密、还原核对（含表权限、列权限、属主）并写校验文件，但跳过 `recovery-baseline.env`。标准错误打印 `baseline_updated=false`。另写 `.state/daily-backup-latest.env`，只有文件名、sha256、核对时间、`BACKUP_FORMAT=2`。
|
||||
- 不设这个前缀时，仍写 `recovery-baseline.env`，里面有 `RECOVERY_FORMAT=2`，标准错误打印 `baseline_updated=true`，不改已经存在的每日记录。
|
||||
- 标准输出仍是原来的 7 行。因此没有改 `.gitea` 里「恰好 7 行」的检查，也没有改四个已有生产工作流。
|
||||
- 再确认清理脚本只删严格匹配的过期 `production-daily-` 文件。既有测试里的 `production-pre-migration-` 手动恢复点仍被保留。
|
||||
- `docs/operations/production-release-runbook-20261014.md` 和 `deploy/README.md` 写明：每日备份只是存档和核对，上线前仍要手动点 Create production recovery。
|
||||
|
||||
## 跑过的检查
|
||||
|
||||
| 检查 | 命令 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 安全网与隐私 | `.venv\Scripts\python.exe -m pytest tests/test_beta_safety_net.py tests/test_repo_privacy_markers.py -q` | 78 通过（安全网 16，隐私 62），退出码 0 |
|
||||
| 前端合同 | `node node_modules/tsx/dist/cli.mjs --test tests/runtime-sources-no-test-imports.test.ts tests/staging-backend-workflows.test.ts` | 46 项：41 通过，5 失败，0 取消。失败是本机缺口，见下方偏离。恢复点工作流的文本检查通过 |
|
||||
| shellcheck | 无 | 本机没有这条命令 |
|
||||
| 前端 tsc / lint / 全量测试 | 未跑 | 没有改网页 |
|
||||
| Python 快速门 | 未跑 | 按本轮约定不跑 |
|
||||
| 数据库测试 | 未跑 | 没有改数据库 |
|
||||
|
||||
## 偏离
|
||||
|
||||
- `baseline_updated` 打在标准错误，避免把每日备份和手动恢复点工作流对标准输出「恰好 7 行」的检查撑破。没有改 `.gitea/**`。
|
||||
- 测试要在临时目录里跑脚本。生产路径检查保持原样；只有 `JYOTISHA_RECOVERY_FIXTURE=1` 时才允许别的目录。会调用恢复脚本的两个工作流都没有设置这个变量。
|
||||
- 本机 Git Bash 没有 `flock`，pytest 的临时目录也不能改 Unix 权限。测试只在自己的 PATH 里放了假的 `docker`、`sudo`、`df`、`install`、`chmod`、`flock`。生产脚本仍调用真命令。
|
||||
- 没有在这台 Windows 上安装到生产，没有点任何生产按钮。主机安装和一次恢复演练仍留给产品。
|
||||
- 前端合同 5 项失败都不是这次改的脚本：本机 Python 没有 yaml 模块（直接跑时退出码 9009）、没有 rsync（退出码 127）、临时目录不能改权限（install 报 Permission denied）、文档范围脚本退出码 49。这四类脚本本次都没改。恢复点脚本的语法检查和文本合同是通过的。
|
||||
@@ -339,7 +339,7 @@
|
||||
| `TASK-release-path-production-fix-20261014.md` | `PROGRESS-release-path-production-fix-20261014.md` | **#74 第 1 次打回**：发布规则成立；测试写死 Windows 路径（Linux 全红）、主机演练依赖主机 node 且会留下生产数据副本、docs-only 头时回滚被拒；另补 CHECK_RELEASE_GATE 断言与 OTP 守卫规范化 | 已修，第 2 次仍未过 | `codex/release-path-production-20261014` |
|
||||
| `TASK-release-path-production-fix2-20261014.md` | `PROGRESS-release-path-production-fix2-20261014.md` | **#74 修复单 2（产品选 A）**：恢复点要带属主与权限，旧格式不得回退；演练按备份里的授权比对，并在真实 PostgreSQL 17 上跑通一次 | 待验收 | `codex/release-path-production-20261014` |
|
||||
| `TASK-beta-safety-net-20261014.md` | `PROGRESS-beta-safety-net-20261014.md` | **内测安全网**：每日备份 + 恢复演练、探活告警、本地错误汇总、日志轮转、按 requestId 查日志。发布通路与 #58 已在开工时的 `origin/staging` 上。主机安装和一次演练留给产品 | 待验收 | `codex/beta-safety-net-20261014`（BUG-1355～1357） |
|
||||
| `TASK-beta-safety-net-fix-20261015.md` | — | **#75 产品选 A**：授权新增每日备份定时工作流，但每日备份不得改写 `recovery-baseline.env`（恢复点仍只手动创建）；另记 `daily-backup-latest.env` | 待领取 | `codex/beta-safety-net-20261014` |
|
||||
| `TASK-beta-safety-net-fix-20261015.md` | `PROGRESS-beta-safety-net-fix-20261015.md` | **#75 产品选 A**：每日备份照常做，但不改当前恢复点；另记 `daily-backup-latest.env` | 待验收 | `codex/beta-safety-net-20261014`（BUG-1358） |
|
||||
| `TASK-beta-capacity-20261014.md` | — | **内测容量**：按用户限流、重计算短排队与对话重试、兑换码当邀请码、staging 10/20 并发压测。**等 #58 合入后开工，压测等 #57 合入** | 待前置 | — |
|
||||
| `TASK-beta-capacity-fix-20261015.md` | — | **#76 第 1 次打回**：`a54f75e5` 限流与短排队逻辑通过；源码文本断言未跟改、插入新测试使隐私白名单行号错位 | 待领取 | `codex/beta-capacity-20261014` |
|
||||
| `TASK-special-lagnas-native-20261008.md` | `PROGRESS-special-lagnas-native-20261008.md` | **特殊上升点原生计算（线上缺陷）**：sync6 U6 运行时调 PyJHora，生产镜像没有 PyJHora → staging 上 Hora/Ghati/Sree/Indu/Pranapada 全 blocked；原生实现、PyJHora 只作冻结对照、快速门禁止运行时 import jhora；最先做 | 已验收（已部署 staging `795b8845`，BUG-1273） | `codex/special-lagnas-native-20261008`（未上线；部署以 `/api/health` 为准） |
|
||||
|
||||
Reference in New Issue
Block a user