fix(release): keep daily backups from stalling when the disk fills
Expired daily files are pruned before a new backup, a verify older than 36 hours raises an alert, and the host monitors call sudo with the production env file. The Linux 0600 check is on the staging quick list. Co-Authored-By: Grok (agent loop)
This commit is contained in:
co-authored by
Grok (agent loop)
parent
14897f0bf3
commit
9455fbfc4f
@@ -36363,3 +36363,48 @@
|
||||
- 复发自:无。
|
||||
- 修复版本:分支 `codex/beta-safety-net-20261014`。本机没有装到生产主机,也没有点生产按钮。原先写成 BUG-1358。再次合并 staging 后该号给了「没有每日自动备份」,本条顺延为 BUG-1361。
|
||||
|
||||
## BUG-1362 | 安全网测试在 Linux 上因环境文件权限失败,而且没进自动门禁
|
||||
|
||||
- 状态:resolved
|
||||
- 首次发现 / 最近更新:2026-10-15 / 2026-10-15
|
||||
- 来源:issue #75 验收打回。修复单 `docs/tasks/TASK-beta-safety-net-fix2-20261015.md`。检索「monitor env」「0600」「test_beta_safety_net」,没有更早的同类记录。
|
||||
- 现象:发布前的全量测试在 Linux 上失败。staging 的自动检查却是绿的,所以这一版能进测试环境,却会挡住以后的上生产检查。
|
||||
- 触发条件:`tests/test_beta_safety_net.py` 写出飞书环境文件后直接跑告警脚本。Linux 上该文件是 0644。脚本拒绝不是 0600 的环境文件。macOS 和 Windows 跳过这项检查。这个测试文件也不在自动门禁的 quick 清单里。
|
||||
- 根因:测试没有把环境文件收成 0600。quick 清单只在发布工作流里才跑全树 pytest,所以 Linux 上的失败没有在 staging 门禁暴露。
|
||||
- 修复:测试写完环境文件后执行 `os.chmod(path, 0o600)`。脚本里的 0600 检查不改。把 `tests/test_beta_safety_net.py` 加进 quick 清单。
|
||||
- 验证:非 Linux 上看不到 Unix 权限位,权限相等断言只在 POSIX 上执行。脚本仍包含「必须是 600」的检查。quick 清单包含这个测试文件。
|
||||
- 防复发:上述权限调用、脚本检查和 quick 清单断言。
|
||||
- 相关记录:BUG-1359。
|
||||
- 复发自:无。
|
||||
- 修复版本:分支 `codex/beta-safety-net-20261014`。
|
||||
|
||||
## BUG-1363 | 磁盘到 70% 后每日备份每天失败,旧文件也不再清理
|
||||
|
||||
- 状态:代码已交,主机安装待产品
|
||||
- 首次发现 / 最近更新:2026-10-15 / 2026-10-15
|
||||
- 来源:issue #75 验收打回。修复单 `docs/tasks/TASK-beta-safety-net-fix2-20261015.md`。
|
||||
- 现象:磁盘用到 70% 以后,每天的自动备份都失败。过期的每日文件不会被删,所以磁盘腾不出来。磁盘告警要到 80% 才响,也没有人看最近一次核对是不是太旧。
|
||||
- 触发条件:备份目录使用率达到 70%。清理步骤写在备份成功之后。`daily-backup-latest.env` 的 `VERIFIED_AT` 超过 36 小时,或这份记录不存在。
|
||||
- 根因:恢复脚本在 70% 时直接退出,工作流因此走不到后面的清理。探活和磁盘告警都不读每日核对时间。
|
||||
- 修复:每日工作流先清理过期的 `production-daily-` 文件,再做备份。磁盘检查同时读取 `VERIFIED_AT`(任务书里的 verified_at 就是这个键)。超过 36 小时或记录不可用时告警一次,重新变新后再发一次已恢复。探活模式不读这份文件。70% 拒绝本身不改。
|
||||
- 验证:工作流文本里清理调用在备份调用之前。虚构时钟下,恰好 36 小时不告警,37 小时告警一次,缺失记录告警一次,变新后发已恢复。告警行不含备份文件名。
|
||||
- 防复发:上述顺序断言和过期告警测试。清理脚本仍只认每日前缀。
|
||||
- 相关记录:BUG-1358、BUG-1359、BUG-1361。
|
||||
- 复发自:无。
|
||||
- 修复版本:分支 `codex/beta-safety-net-20261014`。本机没有装到生产主机,也没有点生产按钮。
|
||||
|
||||
## BUG-1364 | 错误汇总和查日志在生产主机上跑不起来
|
||||
|
||||
- 状态:代码已交,主机安装待产品
|
||||
- 首次发现 / 最近更新:2026-10-15 / 2026-10-15
|
||||
- 来源:issue #75 验收打回。修复单 `docs/tasks/TASK-beta-safety-net-fix2-20261015.md`。
|
||||
- 现象:生产主机上的定时错误汇总会每次失败,一条告警都发不出去。按请求编号查容器日志同样起不来。飞书返回失败时仍像已经发出。同一类错误每 5 分钟重复发。容器日志按服务名而不是时间排序。
|
||||
- 触发条件:cron 直接执行 `error-digest.sh` 或 `find-request-log.sh`,且没有事先导出数据库环境文件。飞书响应体里的 `code` 不是 0。同一错误码在 30 分钟内再次出现。`docker compose logs` 的行首带有服务名前缀。
|
||||
- 根因:这两个脚本直接调用 `docker`,没有 `sudo -n`。也没有把数据库环境文件设成生产路径,编排会去找不存在的 staging 文件。发送命令不检查 HTTP 失败和飞书 `code`。排序把服务名前缀算了进去。
|
||||
- 修复:两个脚本改为 `sudo -n docker compose`,并显式传入生产编排文件和 `../.env.production.database`。飞书请求加上 `--fail`,响应 `code` 必须是 0,失败时不写入已发送记录。同一服务、路由、错误码 30 分钟内不重复发。查日志先去掉行首前缀再按时间排序。
|
||||
- 验证:源码断言命令行含 `sudo -n docker compose` 和生产环境文件,且没有裸的 `docker compose`。虚构飞书响应 `code` 非 0 时本地告警记录为空。30 分钟边界前后各跑一次。带服务名前缀的虚构日志按时间而不是按服务名输出。
|
||||
- 防复发:上述命令形状、发送失败、去重和排序测试。
|
||||
- 相关记录:BUG-1359、BUG-1360。
|
||||
- 复发自:无。
|
||||
- 修复版本:分支 `codex/beta-safety-net-20261014`。本机没有装到生产主机,也没有点生产按钮。
|
||||
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
# 进度 · 内测安全网修复单 2(2026-10-15)
|
||||
|
||||
- 分支:`codex/beta-safety-net-20261014`
|
||||
- 任务书:`docs/tasks/TASK-beta-safety-net-fix2-20261015.md`
|
||||
- 被打回的提交:`5c0d895391b5d0806c98de669a2e9cdcd61e3335`
|
||||
- 先合并最新 `origin/staging`(`32b238cf`),没有改写已经推送的提交。
|
||||
|
||||
## 做了什么
|
||||
|
||||
- 合并时安全网旧编号和内测容量撞号。容量保留 BUG-1355~1357。安全网顺延为 BUG-1358~1361。这次三条例外是 BUG-1362、BUG-1363、BUG-1364。
|
||||
- 飞书测试写完环境文件后改成 0600。脚本里「Linux 上必须是 0600」的检查没改。这个测试文件加进 staging 自动门禁的 quick 清单。
|
||||
- 每日工作流先清理过期的每日备份,再做新备份。磁盘到 70% 时仍会拒绝备份,但旧的每日文件不会因此永远留着。70% 这条拒绝本身没改。
|
||||
- 生产主机上的磁盘检查同时看 `daily-backup-latest.env` 的 `VERIFIED_AT`。缺失,或比现在早超过 36 小时,告警一次;重新变新后再发一次已恢复。探活模式不读这份文件。
|
||||
- 错误汇总和按请求查日志改为 `sudo -n docker`,并显式传入生产编排和 `../.env.production.database`。
|
||||
- 飞书请求加了 `--fail`,响应里的 `code` 必须是 0。失败时不写入已发送记录。同一服务、同一路由、同一错误码 30 分钟内不重复发。
|
||||
- 容器日志先去掉行首的服务名前缀,再按时间排序。
|
||||
- 上一轮「每日备份不改当前恢复点」没有重做。四个已有生产工作流、staging 工作流、`gated-paths.txt`、`is-docs-only-range.sh` 没改。
|
||||
|
||||
## 跑过的检查
|
||||
|
||||
| 检查 | 命令 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 安全网 | `.venv\Scripts\python.exe -m pytest tests/test_beta_safety_net.py -q` | 20 通过,退出码 0 |
|
||||
| 隐私标记 | `.venv\Scripts\python.exe -m pytest tests/test_repo_privacy_markers.py -q` | 62 通过,退出码 0 |
|
||||
| 前端 tsc / lint | 未跑 | 没有改网页 |
|
||||
| Python 快速门 | 未跑 | 按本轮约定不跑 |
|
||||
| 数据库测试 | 未跑 | 没有改数据库 |
|
||||
| shellcheck | 未跑 | 本机没有这条命令 |
|
||||
|
||||
## 断言变更
|
||||
|
||||
| 位置 | 原值 | 新值 | 原因 |
|
||||
| --- | --- | --- | --- |
|
||||
| 飞书测试桩的响应正文 | `ok` | `{"code":0}` | 发送方现在要求飞书 `code` 为 0。请求体字段断言没改 |
|
||||
| 磁盘测试的准备数据 | 不提供每日核对记录 | 提供一份核对时间等于当前时间的记录 | 磁盘模式会同时检查核对时间。没有记录会多一条告警。磁盘告警原文断言没改 |
|
||||
|
||||
## 偏离
|
||||
|
||||
- 任务书写 `verified_at`。上一轮文件里的键是 `VERIFIED_AT`。这次读这个键,没有改名。
|
||||
- 本机 `os.chmod(path, 0o600)` 之后,`stat` 仍是 `0o666`。Windows 存不下 Unix 权限。0600 相等断言只在 POSIX 上执行;`chmod` 每次都会调用。Linux 上的脚本检查保持原样。
|
||||
- 没有在这台 Windows 上安装到生产,没有点任何生产按钮。主机安装和恢复演练仍留给产品。
|
||||
@@ -340,7 +340,7 @@
|
||||
| `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-1358~1360) |
|
||||
| `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-1361) |
|
||||
| `TASK-beta-safety-net-fix2-20261015.md` | — | **#75 修复单 2**:生产侧全过;飞书测试 env 文件权限 0644 在 Linux 上失败(会挡发布门禁);新测试不在 quick 门禁;磁盘 ≥70% 后备份静默停摆;监控脚本缺 sudo 与 env 文件 | 待领取 | `codex/beta-safety-net-20261014` |
|
||||
| `TASK-beta-safety-net-fix2-20261015.md` | `PROGRESS-beta-safety-net-fix2-20261015.md` | **#75 修复单 2**:生产侧全过;飞书测试 env 文件权限 0644 在 Linux 上失败(会挡发布门禁);新测试不在 quick 门禁;磁盘 ≥70% 后备份静默停摆;监控脚本缺 sudo 与 env 文件 | 待验收 | `codex/beta-safety-net-20261014`(BUG-1362~1364) |
|
||||
| `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