2026-09-10 01:16:31 +08:00
1 changed files with 9 additions and 0 deletions
@@ -870,3 +870,12 @@ Core 的独立数据目录目前不等于已授权 Vault。Python 旧笔记写
 - 分页从 revision 100 建立 `limit=7` 的固定快照边界，分页过程中追加 revision 101；结果恰好覆盖 1～100，无缺口和重复，新增 revision 不越过冻结边界。对象在上传完成后可读取，但在首次 revision 提交前同步边界仍为 0；未上传对象的提交固定返回 `OBJECT_NOT_READY`。
 - 200 次关闭连接的健康请求观察到恰好两个随机 worker 标识，证明请求实际落到两个生产 worker；该标识只存在于临时响应头，不暴露主机名、PID 或凭据。Sync 服务全套 29 项通过、2 项依赖弃用警告，runner 6 项自测、Python 编译和源码差异检查通过。
 - 提交 `37ea976` 后在只保留用户 Vault 修改的工作树运行统一 runner，summary/case 均为 `PASSED`，commit 为 `37ea9765b3af3f4ee9e05eac4b24a6947a5ae76f`，7 项断言通过，耗时 19885 ms。证据目录 `H:\OpenNexus-acceptance\s04-37ea976-492072040df647e7be211c27b2c497ad-report\`，报告标记 `contains_credentials=false`。S-04 可记为通过；上传竞态、鉴权/就绪、备份恢复、性能和运维门 S-05～S-07/S-09 仍未完成，整体生产化目标保持未完成。
 ## 增量：S-05 上传持久性、完成回执与清理竞争生产验收
 - 修复暂存文件短于数据库 offset 的恢复语义。服务先结束检测事务，再按相同 Vault 行锁顺序在独立事务中删除损坏暂存与上传记录，立即释放配额预留，随后返回 `UPLOAD_DAMAGED/restart_required`；同一旧 upload 不能继续写，重新申请可获得新 upload 并从零重传。暂存长于 offset 时仍先截断、刷新并 `fsync`，不会把未提交尾部作为已确认字节。
 - 实栈反复完成小对象时发现高层 S3 transfer manager 会出现请求停滞；改为单次流式 `PutObject`。对象上限 100 MiB，低于 S3 单 PUT 的 5 GiB 上限，上传不缓存完整对象。修复后的两次直接实栈运行以及提交绑定的正式 runner 都越过旧停滞位置并完成全部对象读回。
 - S-05 driver 在 PostgreSQL 17.11、固定 MinIO 和两个生产 Uvicorn worker 上执行五组 100 轮：同 offset 双请求每轮恰好一项写入，数据库 offset 与暂存长度一致；磁盘超前被截断，磁盘落后被标损并重传；客户端发送 complete 后不读取响应，服务完成并删除暂存后，同 upload 回放两次均返回持久回执；过期清理与 complete 同时竞争，受控交错得到 50 次 complete 胜出和 50 次 cleanup 胜出。
 - 最终 450 个已引用对象全部经鉴权重新下载并逐字节核对，50 个清理胜出的摘要全部返回 `OBJECT_NOT_FOUND`；对象数与完成回执数一致，Vault 已用额度精确为 11450 字节，上传记录、预留字节和暂存文件均为 0。最大清理完成延迟为 803 ms，低于到期后 15 分钟门槛。
 - 提交 `34fba9a` 后在只保留用户 Vault 修改的工作树运行统一 runner，summary/case 均为 `PASSED`，commit 为 `34fba9abe4519f70bc18614be5cab3e75f1f3d1a`，7 项断言通过，耗时 91833 ms。证据目录 `H:\OpenNexus-acceptance\s05-34fba9a-de9ffa38be6d4d2a9405f1940ffbef49-report\`，报告标记 `contains_credentials=false`。Sync 服务全套 29 项、runner 6 项、Python 编译与差异检查通过。S-05 可记为通过；鉴权/就绪、备份恢复及性能运维门 S-06/S-07/S-09 仍未完成，整体生产化目标保持未完成。