root/Jyotisha
1
0
Fork 0
Code Issues 30 Pull Requests Actions Packages Projects Releases Wiki Activity

fix(release): keep owners and grants in production recovery points

Browse Source 
Co-Authored-By: Grok (agent loop)
This commit is contained in:
jesse-ux
2026-10-14 21:01:52 +08:00
co-authored by Grok (agent loop)
parent d13250f40a
commit 09906cdccc
13 changed files with 381 additions and 145 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/BUG_HISTORY.md
+15
View File
@@ -36116,3 +36116,18 @@
- 相关记录：BUG-1348。
- 复发自：无。
- 修复版本：分支 `codex/release-path-production-20261014`。编号在 BUG-1347 之后。
## BUG-1350 | 生产恢复点不含属主与权限，整库还原后网站账号无权限
- 状态：fixed-pending-verify（本机 PostgreSQL 17 演练已通过；生产按钮还没点，不能标 resolved）。
- 首次发现 / 最近更新：2026-10-14 / 2026-10-14
- 来源：issue #74 第 2 次验收未过。任务书 `docs/tasks/TASK-release-path-production-fix2-20261014.md`。产品选 A，授权改备份工具。
- 现象：按 8 月以来的恢复点整库还原后，网站用来查询的账号对表没有权限，站点请求会被拒绝。恢复点旁边的四个计数仍然对得上，看不出权限丢了。
- 触发条件：用现有生产恢复点工具做备份再还原。该工具导出时丢掉属主和授权。
- 根因：导出和还原核对都丢掉属主和授权，核对只数行。8 月的恢复点工具就是这样写的。这不是 BUG-203。那条是恢复点锁文件的所有权漂移，锁和这次的授权不是同一件事。
- 修复：导出只保留自定义格式。还原核对比较源库和还原库的表权限、列权限、表属主，三者不一致就不写恢复点记录。记录里的格式版本是 2。部署和迁移只有在允许回退、并且这份记录的版本不低于 2 时才继续，否则提示先做新的恢复点。演练不再改类型属主，改为比对迁移有没有收回原有授权，并检查服务角色对人物表各列的读取权。新的一次性库补上迁移角色的连接和建对象权限，因为整库导出带不走数据库本身的权限。
- 验证：本机 PostgreSQL 17 演练见 `docs/testing/production-migration-rehearsal-20261014.md`。权限三样一致，演练退出码 0，`rehearsal_ok=1`，演练库已删除，网站角色读到 1 行。生产按钮没点。
- 防复发：工作流文本合同锁住导出不再丢掉属主和授权，并锁住格式版本 2。演练测试锁住不再改类型属主、要比对收回的授权。
- 相关记录：BUG-203（锁文件，不是这一条）、BUG-1063（人物表列级读取权）、BUG-1348。
- 复发自：无。
- 修复版本：分支 `codex/release-path-production-20261014`。编号接在 BUG-1349 之后。
docs/operations/production-release-runbook-20261014.md
+36 -10
View File
@@ -37,7 +37,7 @@ Gitea → Jyotish Release Quality Gate → Use workflow from：`main`。不需
Gitea → Create Production Recovery Point。Use workflow from：`main`。`deploy_sha` 填 `R`。
通过：成功结束，记下三样东西：`recovery_reference`、`recovery_created_at`、以及它已经写明还原验证通过。加密备份在生产主机的备份目录里，不要打开、不要把密钥贴出来。
通过：成功结束，记下三样东西：`recovery_reference`、`recovery_created_at`、以及它已经写明还原验证通过。主机上的 `/opt/jyotisha-production/.state/recovery-baseline.env` 里必须有 `RECOVERY_FORMAT=2`。没有这一行，或者数字小于 2，都不要往下走：先再点一次创建恢复点。8 月以来不带权限的旧备份不能再拿来回退。加密备份在生产主机的备份目录里，不要打开、不要把密钥贴出来。
失败：停。不要迁移。
@@ -59,7 +59,7 @@ DEPLOY_PATH=/opt/jyotisha-production JYOTISHA_REHEARSAL_PLAN=1 bash deploy/rehea
DEPLOY_PATH=/opt/jyotisha-production RECOVERY_DUMP=/opt/jyotisha-production/backups/<刚才那个备份文件名> bash deploy/rehearse-production-migrations.sh
```
脚本只还原到一次性库，不会改名为 `jyotisha` 的生产库。磁盘使用率要低于 70%。另一项生产变更正在进行时会停。跑完会删掉一次性库。
脚本只还原到一次性库，不会改名为 `jyotisha` 的生产库。新库带不走原来的建库权限，所以脚本只在这个一次性库上，把连接和建对象的权限交给迁移角色。生产库不动。磁盘使用率要低于 70%。另一项生产变更正在进行时会停。跑完会删掉一次性库。
通过，要同时满足：
@@ -67,10 +67,11 @@ DEPLOY_PATH=/opt/jyotisha-production RECOVERY_DUMP=/opt/jyotisha-production/back
- `archived_sessions_before` / `archived_sessions_after`：归档标记还在的会话数。迁移后应为 0。旧备份里还没有这一列时，前面那个数是 `absent`。
- `self_chart_rows_before` / `self_chart_rows_after`：人物表里「本人」那一行。迁移后应为 0。还没有 `role` 列时，前面那个数是 `absent`。
- `notice_lines`：两批迁移日志里 `notice` 的行数。标题修补和自动标题回填的数字在这些行里。生产上标题修补预期是 0；不是 0 就停，只报数字。
- 权限冒烟三行都是 `true`：网页角色能读账户资料、能读会话列表，服务角色能读人物表。这是演练库里的授权（备份里原来的授权，加上这次迁移新给的），不是去问正在服务的那一个生产库。
- 最后一行是 `rehearsal_ok=1`。
- `revoked_grants=0`。这是迁移前后授权的差：迁移不能收回备份里已经有的表权限或列权限。不是 0 就停，不要点生产迁移。
- `chart_profiles_service_role_select_missing=0`。这是服务角色对人物表每一列的读取权，缺几列这里就是几。不是 0 时脚本退出码是 4，并停住。不要点生产迁移。
- 最后一行是 `rehearsal_ok=1`，并且命令的退出码是 0。只看见这一行但退出码不是 0，不算通过。
服务角色读人物表若仍是 `false`，脚本退出码 4，并停住。不要点生产迁移。演练库删不掉时，脚本不再只是警告：退出码不是 0，并写出「演练库未删除，请手动 DROP DATABASE rehearse_…」。生产库还没动。把退出码和它打印的那一句原因留下来。不要复制数据库口令或备份密钥。
演练结束后，在 postgres 容器里执行 `\l rehearse_*`，确认没有名字以 `rehearse_` 开头的库留下来。演练库删不掉时，脚本退出码不是 0，并写出「演练库未删除，请手动 DROP DATABASE rehearse_…」。只删它写出的那一个名字，不要删名为 `jyotisha` 的生产库。生产库还没动。把退出码和它打印的那一句原因留下来。不要复制数据库口令或备份密钥。
## 6. Migrate Production Database
@@ -103,16 +104,41 @@ Gitea → Deploy production。Use workflow from：`main`。
旧代码读不了新的表结构。所以不能只把程序退回去。两件事都要做，都由产品负责人点，不要让执行代理代点。
1. 整库还原。没有单独按钮。第 4 步的 `recovery_reference` 斜杠后面就是备份文件名，例如 `production-pre-migration-20261014T120000Z.dump.enc`。文件在 `/opt/jyotisha-production/backups/` 下面。先 `sha256sum` 这个文件，和 `/opt/jyotisha-production/.state/recovery-baseline.env` 里的 `RECOVERY_SHA256` 对上，再继续。工具和创建恢复点时一样，都在 `deploy/run-production-recovery.sh` 里：`openssl` 解密，再在 postgres 容器里 `pg_restore`。这一步会清掉现在的生产库 `jyotisha` 再装回备份。先停 `api` 和 `web`，不要停 `postgres`。在 postgres 容器里删除并重建名为 `jyotisha` 的库（只动这一个），然后：
1. 整库还原。没有单独按钮。只允许 `RECOVERY_FORMAT=2` 的恢复点。先看 `/opt/jyotisha-production/.state/recovery-baseline.env`：没有 `RECOVERY_FORMAT=2` 就停，回到第 4 步再点一次创建恢复点。8 月的旧备份不能用。第 4 步的 `recovery_reference` 斜杠后面就是备份文件名，例如 `production-pre-migration-20261014T120000Z.dump.enc`。文件在 `/opt/jyotisha-production/backups/` 下面。先 `sha256sum` 这个文件，和同一份 `recovery-baseline.env` 里的 `RECOVERY_SHA256` 对上，再继续。
先停 `api` 和 `web`，不要停 `postgres`。口令和密钥只用主机上已有的环境文件，不要贴出来。
```text
api_id=$(sudo -n docker ps -q --filter label=com.docker.compose.project=jyotisha-production --filter label=com.docker.compose.service=api)
web_id=$(sudo -n docker ps -q --filter label=com.docker.compose.project=jyotisha-production --filter label=com.docker.compose.service=web)
sudo -n docker stop $api_id $web_id
postgres_id=$(sudo -n docker ps -q --filter label=com.docker.compose.project=jyotisha-production --filter label=com.docker.compose.service=postgres)
sudo -n docker exec -e PGPASSWORD="$POSTGRES_PASSWORD" "$postgres_id" \
psql -U "$POSTGRES_USER" -d postgres -v ON_ERROR_STOP=1 \
-c "DROP DATABASE jyotisha WITH (FORCE);"
sudo -n docker exec -e PGPASSWORD="$POSTGRES_PASSWORD" "$postgres_id" \
psql -U "$POSTGRES_USER" -d postgres -v ON_ERROR_STOP=1 \
-c "CREATE DATABASE jyotisha;"
openssl enc -d -aes-256-cbc -pbkdf2 -pass env:PRODUCTION_BACKUP_ENCRYPTION_KEY -in <备份文件> \
| sudo -n docker exec -i -e PGPASSWORD="$POSTGRES_PASSWORD" <postgres容器> \
pg_restore -U "$POSTGRES_USER" -d jyotisha --no-owner --no-acl --exit-on-error
| sudo -n docker exec -i -e PGPASSWORD="$POSTGRES_PASSWORD" "$postgres_id" \
pg_restore -U "$POSTGRES_USER" -d jyotisha --exit-on-error
sudo -n docker exec -e PGPASSWORD="$POSTGRES_PASSWORD" "$postgres_id" \
psql -U "$POSTGRES_USER" -d jyotisha -v ON_ERROR_STOP=1 \
-c "GRANT CONNECT, CREATE ON DATABASE jyotisha TO schema_owner;"
```
口令和密钥只用主机上已有的环境文件，不要贴出来。还原后数这四样，要和备份旁边的 `*-restore-verify.json` 里 `checks` 一致：`identity.users`、`public.profiles`、`public.credit_transactions`、`public` 里的表数量。对不上就停，不要部署。
整库导出带不走数据库本身的权限。上面这一句只补回迁移角色在这个库上的连接和建对象权限，和主机最初的引导一致。不要删掉空的 `public`，备份会改它的属主，先删会让还原停住。
2. 再点 Deploy production，`allow_rollback` 选 true，目标用发布前的生产版本 `7b620c7a`。测试环境头如果只多了文档、自己没有门禁记录，回滚用的控制器仍然是最近一次门禁通过的修订，不再因为这个被拒绝。目标版本仍必须在已经审查过的 main 历史里。
还原后数这四样，要和备份旁边的 `*-restore-verify.json` 里 `checks` 一致：`identity.users`、`public.profiles`、`public.credit_transactions`、`public` 里的表数量。同一份 `checks` 里 `table_grants_match`、`column_privileges_match`、`table_owners_match` 必须都是 true。这三样是创建恢复点时，源库和还原库的表权限、列权限、表属主已经对过。对不上就停，不要部署。
然后再用网站账号实际读一行。没有登录身份时，行级安全会把行藏起来，看起来像没读到，但那不是权限不够。先把身份设成库里已有的一条账户，再切换角色。下面这条必须成功（退出码 0），并且能读到一行。权限不够会直接失败，失败就停，不要部署：
```text
sudo -n docker exec -e PGPASSWORD="$POSTGRES_PASSWORD" "$postgres_id" \
psql -U "$POSTGRES_USER" -d jyotisha -v ON_ERROR_STOP=1 \
-c "select set_config('request.jwt.claim.sub', (select id::text from public.profiles limit 1), false); set role authenticated; select 1 from public.profiles limit 1;"
```
2. 再点 Deploy production，`allow_rollback` 选 true，目标用发布前的生产版本 `7b620c7a`。点之前先在 Gitea 的 Actions 运行列表里确认：这个版本有一次成功的手动发布门禁（Release Quality Gate）。查不到就停，问产品负责人，不要点。测试环境头如果只多了文档、自己没有门禁记录，回滚用的控制器仍然是最近一次门禁通过的修订，不再因为这个被拒绝。目标版本仍必须在已经审查过的 main 历史里。回滚如果提示恢复点格式低于 2，同样先回到第 4 步创建新恢复点，不要改用旧备份。
还原并且部署成功之后，再按核对清单看健康检查。版本号应回到 `7b620c7a`。
docs/tasks/PROGRESS-release-path-production-fix2-20261014.md
+41
View File
@@ -0,0 +1,41 @@
# PROGRESS · 发布通路修复单 2（2026-10-14）
- 分支：`codex/release-path-production-20261014`
- issue：#74。先并入当时的 `origin/staging`（合并提交 `d13250f4`），没有改写已推历史。
- 产品选 A：恢复点带上属主和权限，并在本机真实 PostgreSQL 17 上演练。没有点生产按钮。
- 新记录：BUG-1350。不是 BUG-203 的复发。BUG-203 是恢复点锁文件的所有权。
## 做了什么
1. 恢复点导出只保留自定义格式。还原后比较表权限、列权限、表属主，不一致就不写恢复点记录。记录里写 `RECOVERY_FORMAT=2`。创建恢复点的按钮输出仍是原来的 7 行，那个工作流文件没有改。
2. 部署和迁移在允许回退时，读主机上的恢复点记录。版本低于 2 就拒绝，并提示先做新的恢复点。正向部署不要求这份文件。
3. 演练不再改类型属主。迁移前后比较授权，收回了原有授权就退出 1。人物表列级读取权缺了就退出 4。新的一次性库补上迁移角色的连接和建对象权限，因为整库导出带不走数据库本身的权限。
4. 手册的整库还原去掉丢掉属主和授权的参数。还原后补回迁移角色在这个库上的连接和建对象权限。读网站账号之前先设登录身份，否则行级安全会把行藏起来。
## 和任务书不完全一样的地方
- 空库必须留着 `public`。备份是去改它的属主，不是重新创建它。先删掉会停在「schema public 不存在」。
- 数归档会话时，列还不存在不能写在同一条查询里，数据库会在解析阶段就拒绝。先看列在不在，再计数。没有这一列时仍输出 `absent`。
- 本机演练用的是 fixture 里的 PostgreSQL 17，不是生产主机上的那一份备份。生产恢复脚本要求生产目录，不能在这台电脑上原样执行。导出参数、加密方式和还原核对是按脚本重放的。
## 自测
| 命令 | 结果 |
| --- | --- |
| `bash -n` 四个生产脚本 | 退出码 0 |
| `tests/test_rehearse_production_migrations.py` | 6 通过，退出码 0 |
| `tests/test_resolve_release_revision.py` 与上一份一起 | 13 通过，退出码 0（授权那条断言是在这之后加上的，演练测试又单独跑过） |
| `tsc --noEmit -p frontend` | 退出码 0 |
| `npm run lint --prefix frontend` | 退出码 0，0 error，123 条原有 warning |
| `frontend/tests/staging-backend-workflows.test.ts` | 44 条里 39 通过、5 失败、0 取消。失败是这台 Windows 机器的环境：python 退出码 9009、两条缺 rsync、临时目录改权限被拒绝、纯文档范围脚本退出码 49。生产部署、恢复点、生产迁移合同（第 32、34、35、36、37 条）通过 |
| 本机 PostgreSQL 17 演练 | 见 `docs/testing/production-migration-rehearsal-20261014.md`。权限三样一致，`rehearsal_ok=1`，退出码 0，演练库 0 个残留，网站角色读到 1 行 |
## 预检
`scripts/pre_work_check.py --remote-timeout 8 --command-timeout 45` 退出码 1。远端仓库可见，适配器正常。碎片扫描 90 秒超时，聚焦测试 45 秒超时。这是这台电脑上预检超时的老问题，没有改台账，也不写成预检通过。
## 没做
- 没有点生产按钮，没有连生产主机。
- 没有推 `staging` 或 `main`。
- 没有改测试环境工作流、门禁路径清单、纯文档判断脚本。
docs/tasks/README.md
+1 -1
View File
@@ -336,7 +336,7 @@
| `TASK-beta-main-path-fix-20261014.md` | `PROGRESS-beta-main-path-20261014.md` | **#73 第 1 次打回**：`fca62fda` 内容通过；与 #63 删除的旧报告视图有代码冲突，接受删除即可 | 待验收 | `codex/beta-main-path-20261014` |
| `TASK-release-path-production-20261014.md` | `PROGRESS-release-path-production-20261014.md` | **发布通路 + 生产首发**：产品 10-14 授权改生产工作流（发布 SHA = 最近门禁成功提交 + 其后纯文档）；63 个迁移清单与演练脚本、首发 runbook；生产拒绝测试验证码。Grok 不 dispatch 生产工作流 | 第 2 次打回后续修 | `codex/release-path-production-20261014`（BUG-1348、BUG-1349） |
| `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-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` | — | **内测安全网**：每日备份 + 恢复演练、探活告警、本地错误汇总、日志轮转、按 requestId 查日志。**等发布通路单合入、#58 合入后开工** | 待前置 | — |
| `TASK-beta-capacity-20261014.md` | — | **内测容量**：按用户限流、重计算短排队与对话重试、兑换码当邀请码、staging 10/20 并发压测。**等 #58 合入后开工，压测等 #57 合入** | 待前置 | — |
| `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` 为准） |
docs/testing/production-migration-rehearsal-20261014.md
+37 -21
View File
@@ -1,25 +1,41 @@
# 生产迁移演练报告（模板）
# 生产迁移演练记录（2026-10-14）
产品在主机上跑完 `deploy/rehearse-production-migrations.sh` 后填写。只写行数和通过/停止。不要写姓名、出生时间、邮箱、会话正文、密钥或任何一行的内容。
本机 Docker，镜像 `postgres:17-alpine`，和 `npm run test:db` 用的是同一个 fixture。没有连生产主机，没有点生产按钮。数据是虚构的，每种关键表一行。下面只记计数、退出码和是否一致。
| 项 | 结果 |
## 步骤
1. 建库后套用生产当前版本：`frontend/db/migrations` 全部，加上 `frontend/supabase/migrations` 里文件名早于 `20260816010000` 的文件。Windows 上有 4 个同名文件，内容一致，只留一份。
2. 用恢复脚本同款方式导出：`pg_dump --format=custom`。再用 openssl `aes-256-cbc -salt -pbkdf2` 加密，然后解密。密钥没有写进仓库。
3. 新建空库，`pg_restore --exit-on-error`。不先删 `public`。用超级用户比较源库和还原库的表权限、列权限、表属主。
4. 再还原一份，跑 `deploy/rehearse-production-migrations.sh` 的本地模式。
5. 再按手册还原一份。先把登录身份设成库里已有的一条账户，再 `set role authenticated`，读 `public.profiles`。
## 结果
| 项 | 值 |
| --- | --- |
| 日期 | |
| 发布修订 R | |
| 恢复点引用 | |
| 一次性库名字（必须是 `rehearse_` 开头） | |
| `other_person_accepted_rows` | 预期 0 |
| 归档会话：迁移前非空行数 / 迁移后 | 迁移后应为 0 |
| 人物表里本人镜像：迁移前 / 迁移后 | 迁移后应为 0 |
| 标题修补两条 NOTICE | 生产上预期都是 0。不是 0 就停止 |
| 自动标题回填 NOTICE | 只写数字 |
| 未知时间改成时段比较的行数 | |
| 家人整点改为已采用的行数 | |
| 时段回填的行数 | |
| 无日期证据改为已确认的行数 | |
| 网页角色读账户资料 | true 才算过 |
| 网页角色读会话列表 | true 才算过 |
| 服务角色读人物表 | true 才算过。false 时脚本退出码 4，停止，不要点生产迁移。这是演练库里的结果，不是正在服务的生产库 |
| 最终一行 | `rehearsal_ok=1` 才算演练通过 |
| 基线迁移文件 | 111 |
| 基线迁移退出码 | 0 |
| 基线已应用 | 111 |
| 源库计数（身份账户 / 账户资料 / 点数流水 / 人物表 / public 表） | 1 / 1 / 1 / 1 / 76 |
| 加密退出码 | 0 |
| 解密退出码 | 0 |
| 表权限一致 | true（871 行） |
| 列权限一致 | true（6760 行） |
| 表属主一致 | true（75 行） |
| 演练第一批文件 | 160 |
| 演练全部文件 | 175 |
| 演练退出码 | 0 |
| archived_sessions_before | absent |
| archived_sessions_after | 0 |
| self_chart_rows_before | 0 |
| self_chart_rows_after | 0 |
| other_person_accepted_rows | 0 |
| notice_lines | 161 |
| revoked_grants | 0 |
| chart_profiles_service_role_select_missing | 0 |
| rehearsal_ok | 1 |
| 结束后名字以 rehearse_ 开头的库 | 0 |
| authenticated 读到的行 | 1 |
停止时：生产库不应被修改。把脚本打印的那一句原因贴在这里，去掉任何连接地址。
`notice_lines=161` 是这次空库演练里迁移提示的行数，不是生产上的标题修补人数。生产上仍按手册：标题修补不是 0 就停。