minio/docs/investigations/r6/README.md

# R6：delete-marker purge 与 MRF 修复

## 当前交付状态

本地实现已完成，v3 已与真实 Opus 5.0 达成共识。原研究基线和同步到主干快照后的定向回归、race、完整构建、vet、lint 全部通过；此前受宿主机容量限制的六项 DELETE 测试，在空间恢复后也全部通过。

- 研究基线：`9ebe81c1b3611f9cc73e676b5b741c2be62c467a`。
- 集成基线：`af2b1794d38d9e70e1d2c3ee692426e4b6cab4bd`；通过最终验证的源码提交：`cf381a7151ef25fc95ace5fedcd767fa19410de2`。后续提交仅整理本目录的验证文档。
- 分支：`codex/r6-delete-marker-mrf`。
- [PR #184](https://github.com/pgsty/silo/pull/184) 在最终核对时仍为 OPEN，head `6addf9eb916b5a4b837480cf534cd1efa5407d3c`。复用其按 purge 状态识别操作、接纳 marker 405 的方向，补齐实测遗漏；没有直接合并该 PR。
- 从研究基线到集成基线，仅新增 R4 的 SSE-KMS PUT 选项与对应材料，R6 涉及的生产文件、测试文件和依赖未发生交叉修改。五个 R6 文件在同步前后的 SHA256 一致。
- 本任务没有执行主干合并、远端推送、发布、部署或现网存量改写。

## 修复内容

| 操作 | 远端行为 | 结果与源端写回 |
|---|---|---|
| marker 创建 | 保留 HEAD 已存在/就绪检查及创建语义 | 更新创建状态；405 可以表示已创建 |
| 规范版本 purge | 发送指定 versionId 的永久删除 | 只更新 purge 状态，保留磁盘创建/replica 字段 |
| 旧 marker 形态 purge | 从任务级 purge 状态识别，沿用规范永久删除请求 | 不再被创建 COMPLETED 跳过；失败进入 MRF；已完成 purge 不重发 |

- 离线、DELETE 拒绝、成功与 resync 出口使用操作自己的状态；失败 purge 不写成功 reset 标记。源端 purge 写回显式清空三个“创建更新”字段，避免多目标空状态被旧正则误解析后覆盖磁盘创建记录。
- MRF 接受携带正确 marker、版本、对象、桶和非零时间的 405；其它错误或无效信息不调度删除。
- 删除任务携带重试计数；锁失败、复制失败、工作队列满三个入 MRF 出口都递增。耗尽现有预算后继续保留 scanner 恢复路径。
- purge 的内部 COMPLETE 保持不变；操作审计使用规范 COMPLETED，失败为 FAILED。按目标状态变化更新统计，成功 heal purge 的统计为次数增加、字节数为零。
- 不改 wire 格式、MRF 磁盘格式、共享正则、复制状态合并框架或依赖版本。

## 真实 Opus 共识

使用本机 Claude Code 2.1.270，每轮显式指定 `claude-opus-5 --effort max`。全部记录到的 assistant 模型均为 `claude-opus-5`；实际调用成功，未用模拟评审或限流失败代替同意。

| 方案 | 结论 | 处置 |
|---|---|---|
| v1 | REVISE，1 个阻断 | 接受意见：不能用本次目标子集重写完整创建状态 |
| v2 | GO_WITH_NONBLOCKING_NOTES | 共识后实现；随后用真实存储发现多目标空状态正则反例 |
| v3 | GO_WITH_NONBLOCKING_NOTES，0 阻断 | reviewer 撤回过强的旧证明，确认三字段清空方案；共识后应用并验证 |

最终不可变方案：[plan-v3.md](plan-v3.md)，SHA256 `dc9a67fc91b3113fa35218a2f903455807430cc4daf9c78a88d0be6b8fc27058`。
详见 [完整共识及逐项处置](consensus.md)、[研究与 #184 审查](research.md)、[v3 原始评审正文](opus-v3-review.md)。模型只读权限不允许计算哈希；它核对了具体文件内容，本任务在评审前后计算并确认哈希不变。评审不替代执行验证。

## 验证范围

原基线证据：[机器记录](verification/baseline-verification.json)。最终集成证据：[五项检查记录](verification/rebased-verification.json)、[六项 DELETE 复验](verification/rebased-delete-verification.json)、[源码与方案哈希清单](final-source-manifest.json)。对应日志在同目录，均与原始日志逐字节一致。运行环境：Go 1.27.1，darwin/arm64，GOMAXPROCS=4。

| 检查 | 最终结果 |
|---|---|
| `go test -p 2 ./cmd ./internal/bucket/replication -run 'TestReplication\|TestReplicate\|TestMRF\|TestResync\|TestSiteResync' -count=1 -v` | 通过，28 个顶层测试 / 198 个通过条目 |
| `go test -race -p 2 ./cmd -run 'TestReplicateDelete\|TestReplicationMRF\|TestReplicationDeleteQueueFull' -count=1 -v` | 通过，无数据竞争报告 |
| `go build -p 2 ./...` | 通过 |
| `go vet -p 2 ./cmd ./internal/bucket/replication` | 通过 |
| golangci-lint 2.13.1，仓库配置，`--build-tags kqueue` | 通过，0 issues |
| 原容量失败的六项 DELETE 测试，按完整测试名精确复跑 | 六项全部通过 |

- 28 个顶层定向测试通过，包含 198 个通过条目（含子测试）。
- 单盘、16 盘真实 erasure 存储；真实源端签名 DELETE、minio-go HTTP、源/目标 marker 元数据。
- 失败 → MRF 文件持久化 → 新 ReplicationPool 读取 → 真实 marker+405 lookup → 工作队列 → 生产 replicateDelete → 恢复。
- 覆盖创建/旧新 purge、部分目标重试、两目标一成一败/离线、远端已删除但响应丢失、重试预算耗尽和 scanner 接管；恢复后核对源和目标 marker 最终状态。
- 两个目标空状态的实际存储反例已转绿；所有 purge 写回均通过断言确认创建字段为空，完整创建/replica 元数据和时间戳保留。
- 验证实际审计 webhook 的 FAILED/COMPLETED，以及失败/成功统计变化；race 未报告数据竞争。

**边界：** 目标为受控 HTTP 适配器，调用真实 ObjectLayer；测试显式消费队列并执行生产复制函数，直接驱动 MRF 保存，没有启动后台定时器和完整 worker 循环。这是三端点 fan-out 与磁盘恢复验证，不是三台独立 SILO 进程的站点复制集群、接收端认证或进程崩溃验收。

首次扩大测试中，六项无关 DELETE 测试在种子数据写入时触发宿主机容量阈值，该次测试未通过。空间恢复后，保持代码不变精确复跑六项，全部通过；这不等于运行了整个 cmd 测试集。R6 存储夹具使用仓库现有容量适配器，数据仍真实落盘。一次测试链接遇到磁盘空间耗尽，清理可确认属于本任务的旧 Go 缓存后复验。详情和中间失败记录：[verification-notes.md](verification-notes.md)。

## 仍然独立的事项

当前 DELETE/scanner/heal/resync 已产生规范 purge；旧任务形态不会序列化跨重启，不能宣称所有失败 purge 永久卡住。本修复主要恢复活跃的 marker MRF 路径，并完善旧形态兼容。

未覆盖或未修改：缺失客户端导致的目标状态遗漏、目标级 resync 的既有 purge 子集替换、复制跟踪已丢失、replica relay、purge 后延迟创建且无 tombstone、源端元数据写失败依赖 scanner、共享解析器的通用健壮性、额外 backoff/指标设计。完整多进程站点验收应另行安排。

原始大日志与临时复现：`/Users/vonng/tmp/silo-r6-20260915-aa3f/`。每轮 metadata 记录模型、命令、基线、方案及原始输出哈希。