Revise the recovery proposal to r2 with external review findings
Why: absorb the external source-review round - pin the shutdown budget change, close the U1 acceptance gap for program/cwd changes, gate U4 public states on a mapping table, and make the svc-autorecover coordination an explicit human decision. Evidence: SELF - external review round 2 in the review record; r2 SHA256 9cfda2520b913e6966c68fb3f66fb7bc8382a8f7a2b69cb364122216dcdb72cd; all reviewed claims re-verified against the pinned baselines. Impact: documents only; four targeted amendments (U1/U3/U4/section 9) plus version bump and INDEX update; requirements and metrics unchanged. Refs: Dev task card .task/feature-service-restart-recovery-plan.md
This commit is contained in:
@@ -7,9 +7,10 @@ execution: code
|
||||
product_contract_source: ce-plan-bootstrap
|
||||
---
|
||||
|
||||
# 服务重启与全量数据恢复方案 r1
|
||||
# 服务重启与全量数据恢复方案 r2
|
||||
|
||||
确认状态：待人工评审。当前交付为源码调查、方案与实施/验收计划；业务实施、故障注入、部署、运行验收均为 NOT_RUN。
|
||||
修订记录：r1＝2026-10-12 初稿并完成六角色文档自审（见同名审阅记录第一轮）；r2＝2026-10-12 吸收外部源码复核（U1/U3/U4/第9节四处修订，见审阅记录第二轮），需求范围与量化指标未变。
|
||||
需求来源：2026-10-12（Asia/Shanghai）用户要求“系统应该在停止并再次启动（通过 svc 或异常终止）后，应当能够恢复所有服务和数据，给我一个完善方案”。负责人：weichen；编制：Codex；实施与运维负责人在启动对应增量时指定。
|
||||
主记录：本文；任务卡：Dev `.task/feature-service-restart-recovery-plan.md`。本文的源码路径以 Dev 根目录为基准。
|
||||
|
||||
@@ -212,7 +213,7 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W
|
||||
|
||||
对应R2/R3/R9；无前置。范围：`scripts/svc.sh`、`docs/svc.md`、`tests/test_svc.py`、`tests/test_svc_precheck.py`及新增manifest/identity验证模块。
|
||||
做完整配置、逐字段覆盖、原子revision与操作锁、稳定秘密引用、DB/数据目录身份marker、独立init/restore入口；保留现有dbref修复并提供旧登记一次性兼容迁移。先补现状刻画回归，再改解析器。
|
||||
验收：连续两次裸启停保持同一DB与原始记录；只改端口保持data/plugins；单独data覆盖按合同生效/拒绝；配置迁移每个写边界kill后只能读到完整旧/新版；缺凭据、错DB、丢marker不得新建空系统。使用真实PG特有测试记录核对，桩测试只能辅助。
|
||||
验收：连续两次裸启停保持同一DB与原始记录；只改端口保持data/plugins；单独data覆盖按合同生效/拒绝；配置迁移每个写边界kill后只能读到完整旧/新版；缺凭据、错DB、丢marker不得新建空系统；更换二进制路径/程序版本或以不同cwd调用svc后，DB identity、数据/工件/工作区根与插件组合保持一致（对应R2更换程序/cwd条款）。使用真实PG特有测试记录核对，桩测试只能辅助。
|
||||
|
||||
### U2. 服务组与进程监管
|
||||
|
||||
@@ -223,13 +224,13 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W
|
||||
### U3. 应用启动、停机与真实就绪
|
||||
|
||||
对应R1/R8/R10；依赖U1，可与U2并行。范围：`modules/backend/internal/app/app.go`、`runmgr/runmgr.go`、`runmgr/events.go`、`plugins/host_v2.go`、server健康接口及其生命周期测试。
|
||||
统一lifecycle context、准入开关、消费者停止与worker join；恢复执行移到装配结束；不同停机原因统一条件结算；sidecar受监督并纳入收口；readiness、恢复摘要和受限诊断按KTD12实现。
|
||||
统一lifecycle context、准入开关、消费者停止与worker join；恢复执行移到装配结束；不同停机原因统一条件结算；sidecar受监督并纳入收口；readiness、恢复摘要和受限诊断按KTD12实现。停机预算属预算来源变更：现状HTTP停机超时仅5秒且超时即返回、跳过后续事件清冲（app.go停机序列，SELF源码核验）；“应用30秒/监管60秒”须显式替换该常量并按最长合法步骤与故障实测校准，不得沿用旧值。
|
||||
验收：插件/预算/Workflow未装好不启动恢复任务；停机同时提交新run被拒；SSE与慢工具不跳过flush/清理；子run不被cancelled覆盖；sidecar崩溃可检测；DB坏/恢复扫描失败不ready；hold不影响无关会话的正常读写。
|
||||
|
||||
### U4. 持久任务恢复与副作用隔离
|
||||
|
||||
对应R4/R5/R7；依赖U3，并复用U5所有权接口；U4/U5作为同一安全交付批次，完整性验收前不开放自动续跑。范围：runmgr/runtime工具入口、store运行/恢复/hold表、checkpoint适配、Core公开状态及Frontend兼容、对应恢复与真实工具替身测试。
|
||||
落实KTD7/KTD8，主run、Workflow、子代理、已配置后台executor共享恢复政策；持久化步骤/输入/结果/operation；自动hold连接到工具与启动扫描。HITL保持gate、答案和权限；修复子代理恢复链唯一性。文件checkpoint仅承担其明确的文件修改范围。
|
||||
落实KTD7/KTD8，主run、Workflow、子代理、已配置后台executor共享恢复政策；持久化步骤/输入/结果/operation；自动hold连接到工具与启动扫描。HITL保持gate、答案和权限；修复子代理恢复链唯一性。文件checkpoint仅承担其明确的文件修改范围；若新增recovering/hold为公开状态，设计阶段先交付Core枚举→Backend→Frontend及下游契约的最小状态映射表，作为设计评审前提。
|
||||
验收：排队/主run/子run/HITL/索引各类任务kill并两次恢复；工具“完成外部动作、结果未提交”只hold不重做；查询暂未发现但外部请求稍后完成时不发送第二次请求；幂等目标使用同operation key；Native pending intent只由统一账本决策，不生成普通错误后绕过hold；确认一个operation完成后执行剩余必要步骤，不假结算整run；未知工具默认隔离；撤权后禁止续跑；无executor类型明确blocked。真实模型最小任务级恢复对照单独申请测试资源，未跑标NOT_RUN。
|
||||
|
||||
### U5. 所有权、额度、命令、通知与投影闭环
|
||||
@@ -273,13 +274,13 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W
|
||||
|
||||
执行时使用项目已有`make test-governance`、`make test-backend-pg`、`make test`、`make build`并增加受管隔离recovery入口。真实PG/Redis/模型/主机测试缺环境时必须明确NOT_RUN或SKIP及缺项，禁止把零用例或条件跳过当通过。按AGENTS要求验收/请求审核/合入前分别task-sync；所有precheck、同步、测试原始输出通过make evidence进入任务卡，并区分SELF/REPLAY/GATE。业务行为面的真实模型验证遵循policy/delivery.md，单测不替代。
|
||||
|
||||
本轮只进行源码与文档检查，业务/数据库身份查询、故障注入、模型试验、迁移、服务启停、部署均NOT_RUN。方案r1不能作为恢复能力验收结论。
|
||||
本轮只进行源码与文档检查，业务/数据库身份查询、故障注入、模型试验、迁移、服务启停、部署均NOT_RUN。方案r2不能作为恢复能力验收结论。
|
||||
|
||||
## 9. 兼容、在途任务与批准事项
|
||||
|
||||
本案补充[多人协作存储与分布式演进方案](2026-10-11-collaboration-storage-and-distribution.md)的R7及恢复/运维合同；不覆盖其批准记录或迁移、多实例放行条件。已存在的执行所有权、命令、outbox实现以当前代码为基础继续，不另起重复模块。
|
||||
|
||||
调查时发现`feature/svc-autorecover`在途工作区，任务卡为manual且目标/方案仍待填；其实施与批准范围未经本轮证实。建议U1/U2复用或协调该任务，把本案r1作为候选需求来源；`feature/collab-storage-u5-outbox`也存在工作区，其变化未纳入当前固定源码。实施前核对当前主记录、卡片、PR、owner及组合SHA，不能依据分支名断言能力已完成。相关RDM/插件只有纳入兼容和恢复清单并验收后才能覆盖“所有数据”承诺。
|
||||
调查时发现`feature/svc-autorecover`在途工作区，任务卡为manual且目标/方案仍待填；其实施与批准范围未经本轮证实。**U1/U2启动实施前必须人工二选一**：(a) 以`feature/svc-autorecover`为实施载体，把本案r2作为其需求与方案来源填入该任务卡后按其流程推进；(b) 记录原因后放弃或合并该任务卡，由本案派生的独立任务实施；两任务不得同时充当svc启动/监管改动的权威，该归属决定与首批实施范围一并报批；`feature/collab-storage-u5-outbox`也存在工作区，其变化未纳入当前固定源码。实施前核对当前主记录、卡片、PR、owner及组合SHA，不能依据分支名断言能力已完成。相关RDM/插件只有纳入兼容和恢复清单并验收后才能覆盖“所有数据”承诺。
|
||||
|
||||
备选：仅修svc脚本成本较小，只能覆盖启动配置/进程，无法满足在途任务和副作用恢复；另造常驻恢复daemon会增加新的监管者与恢复责任，首期无需。推荐现有svc+系统监管+Backend恢复协调的职责划分。
|
||||
|
||||
|
||||
@@ -165,7 +165,7 @@ RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围
|
||||
|
||||
## 2026-10-12 规划补充
|
||||
|
||||
- [服务重启与全量数据恢复方案 r1](2026-10-12-service-restart-data-recovery.md)：2026-10-12 用户要求 svc 停止/再次启动及异常退出后恢复所有服务与数据；覆盖服务依赖/监管、持久配置和数据身份、run/HITL/命令/通知、未知副作用隔离、文件一致性与组合备份。待人工评审；实施/故障注入/部署/运行验收 NOT_RUN。关联协作存储 R7，实施前协调在途 svc-autorecover 与 U5-outbox。
|
||||
- [服务重启与全量数据恢复方案 r2](2026-10-12-service-restart-data-recovery.md)：2026-10-12 用户要求 svc 停止/再次启动及异常退出后恢复所有服务与数据；覆盖服务依赖/监管、持久配置和数据身份、run/HITL/命令/通知、未知副作用隔离、文件一致性与组合备份。r1 经六角色自审，r2 吸收外部源码复核（见同名 review 记录两轮）。待人工评审；实施/故障注入/部署/运行验收 NOT_RUN。关联协作存储 R7，实施前须裁定在途 svc-autorecover 归属（二选一）并核对 U5-outbox。
|
||||
|
||||
## 2026-10-11 规划补充
|
||||
|
||||
|
||||
@@ -33,3 +33,19 @@
|
||||
草稿、入口和子仓改动尚未提交为固定组合；`check-evidence.py`对含未提交非任务卡改动的收据报告`unverified`。原始输出及方案内容摘要已保存，这些记录仅作为本地调查辅助，不能用于正式合入/运行验收。后续正式审核应先固定候选组合、同步并由有权审阅者重放对应检查，不能靠反复执行或更换来源标签消除此限制。
|
||||
|
||||
实施前仍需人工确认故障档/RPO/RTO、目标实例与独占管理权、数据归属清单和在途任务分工。按policy/delivery.md，此次审阅与候选修正不能代替任何阶段的人工批准。
|
||||
|
||||
## 第二轮：外部源码复核（2026-10-11）
|
||||
|
||||
复核者：ZCode 独立上下文；对象：r1（SHA256 `cfc9b768…`）。方法：对主案第2节差距表、基线与自审记录引用的源码断言逐项独立重验；未运行服务、测试或故障试验。来源SELF。
|
||||
|
||||
核验结果（抽查全部命中）：五个基线SHA与任务工作区一致且Dev基线为HEAD祖先；`svc.sh:1373` resolve_db_config统一解析；runmgr `ReconcileInterrupted`（≈2046）统一封印中断；`SetRecoveryHold`与`RenewExecution`均仅有定义、无生产调用；`claimCommand` pending→consumed后执行（kill窗口无重领）；app.go HTTP停机超时（现状5秒）即返回并跳过`mgr.Shutdown`事件清冲；`ListSurfaceEventsPending`默认limit=100；notice启动载入内存队列、投递后独立DELETE非事务；native `loop.go:385–402`工具结果持久化后继续模型回合。
|
||||
|
||||
修订处置（r1→r2，需求与指标未变）：
|
||||
1. U3补停机预算来源变更：现状5秒须显式替换为批准预算并实测校准。
|
||||
2. U1验收补“更换二进制路径/程序版本、不同cwd调用svc后身份一致”场景（对齐R2）。
|
||||
3. U4补“新增公开状态前先交付Core→Backend→Frontend→下游最小状态映射表”。
|
||||
4. 第9节svc-autorecover协调改为明确的人工二选一归属决策项（实施载体 vs 放弃合并，两权威不得并存）。
|
||||
|
||||
流程修订：r1先按被审对象原样提交固定（documents `54fc24e`、Dev `39f719f`），r2为后续修订提交；恢复会话按门禁完成precheck（READY，R0 `555fb2162f`）并task-sync后实施修订。r2 SHA256：`9cfda2520b913e6966c68fb3f66fb7bc8382a8f7a2b69cb364122216dcdb72cd`。
|
||||
|
||||
遗留（人工事项）：svc-autorecover归属二选一、首批实施范围、故障档/RPO/RTO与停机预算批准；全部指标维持待批准未实测。
|
||||
|
||||
Reference in New Issue
Block a user