P4/P5 代码审查后续：计算层 / 存储层 / 调度层问题收敛

[chengda-wu]

背景

基于一次只读代码审查报告，已人工复核当前代码。原报告中部分项严重度偏高或不属实，本 issue 只记录确认属实、值得后续修复/收敛的问题。

当前状态：非计算层主要问题已由 PR #47 修复并合入；计算层问题仍待后续 PR 处理。

参考对照：

• Mooncake transfer-engine：Transport::{allocateBatchID, submitTransfer, getTransferStatus, freeBatchID}，用于校准 transfer/batch 生命周期。
• SGLang：free_group / inc_lock_ref / dec_lock_ref，用于校准 in-flight 冻结与 ref 归零语义。
• Dynamo KVBM：logical / physical / engine 分层，用于校准存储层原型与后续扩展边界。

计算层（待处理）

• runtime/node_scheduler.py::_process_batch_result 对 self._reqs[rid] 直接索引，遇到 stop / abandon / result queue 滞后时可能 KeyError。建议改为 .get(rid) 并跳过已释放请求。
• runtime/role.py::_env_int 遇到非数字环境变量会直接抛 ValueError，导致 worker 启动失败且错误不友好。建议给出明确配置错误或 fallback。
• runtime/worker.py::_abort_rpc 虽然 context.abort() 会 raise，不会真的把 UNAVAILABLE 覆盖成 INTERNAL，但建议显式 return / raise，避免误读和 mock context 下行为不一致。
• runtime/node_scheduler.py 中 _waiting.pop(0) 是 O(n)，schedule() 方法较长；这是后续可维护性/性能优化项，不阻塞当前功能。
• engine/pool_iface.py 中 from_grpc 缺类型标注、probe_prefix 使用 isinstance(InMemoryAgent) 特判，后续可收敛到更明确的 Protocol / adapter 边界。

存储层

• ControlPlane 使用 std::sync::Mutex + lock().unwrap()，mutex poisoning 会级联影响后续请求。已改为显式返回 INTERNAL，并补一次性 poison 告警标记与测试。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• vendored kvbm-logical 的 LineageBackend::insert_inner 重复插入 / hash collision 路径会 panic!。已改为 best-effort no-op，避免外部输入触发控制面 panic。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• storage-agent/src/putend.rs 在 RequestBarrier 失败后静默吞掉 WRITEBACK -1 rollback 错误。已改为 rollback 失败时返回组合错误。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• controlplane/src/reconcile.rs::report_ref_raw 对负引用 underflow 使用 saturating 归零。已改为 underflow/overflow 显式报错并补批量 all-or-nothing 测试。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• tiered-store/src/pipeline.rs::tick 对永久失败 action 无限重试。已增加 retry budget / tombstone 逻辑并补测试。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• tiered-store/src/engine.rs::put_durable rollback 会扰动 LRU 顺序。已在失败回滚时恢复 L2 order，并补测试断言。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• controlplane/src/authority.rs::lookup_prefix / locate clone BlockMeta，当前原型可接受；后续大规模前缀命中路径需评估返回轻量视图或 Arc。（P7 性能校准）
• LocalTierEngine::put_durable 当前为保证回滚正确会保存 L2 order 快照。P4 原型可接受；P7 性能校准时可优化为更轻量的回滚记录。
• ControlPlane::lock_authority poison 告警当前使用一次性 eprintln!。后续引入统一日志框架（tracing / log）时替换为结构化日志。

调度层

• go/router/server.go 使用 io.ReadAll(r.Body)，缺请求体大小限制。已使用 http.MaxBytesReader 限制请求体大小并补测试。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• go/router/server.go 将 JSON 解析错误、gRPC status message 等内部错误直接返回客户端。已改为泛化错误响应，详细原因进日志，并补测试。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• go/router/server.go 创建 gRPC client connection 后未保存/关闭。已保存 conn、提供 Server.Close()，并补 close 测试。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• go/router/cmd/router/main.go 直接 ListenAndServe，无 graceful shutdown。已接入 signal context 和 http.Server.Shutdown。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• Go router 当前无测试覆盖。已补 HTTP handler、错误映射、请求体限制、gRPC mock client、Close 测试。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）
• CLAUDE.md 当前阶段描述仍停留在“即将进入 P1/P2”。已更新为 P4 收敛、P5 推进。（PR fix: 修复 repo cleanup 及调度/存储层 review 问题 #47）

不纳入本 issue 的误报/降级项

• _abort_rpc 的 UNAVAILABLE 正常不会被覆盖成 INTERNAL，因为 context.abort() 会 raise；仅作为可读性修复保留在计算层。
• putend.rs 中 rollback 的 let _ = store.unpin(...) 不会导致“永久 pinned”：未 pin 时才报错，且 discard_settled 会移除 pin。此项不作为正确性 blocker。

下一步

1. 新 PR 处理计算层 5 个待办。
2. P7 性能校准时处理 BlockMeta clone 与 put_durable L2 order 快照成本。
3. 引入统一日志框架时替换 controlplane poison 的 eprintln!。

[chengda-wu]

PR #47 本轮修复后新增后续项（非阻塞）：

• tiered-store::LocalTierEngine::put_durable 为保证失败回滚不扰动 L2 LRU，目前会保存 l2_order 快照。P4 原型可接受；P7 性能校准时可优化为更轻量的回滚记录，避免大 L2 队列下全量 clone。
• ControlPlane::lock_authority poison 告警当前使用一次性 eprintln!。后续引入统一日志框架（tracing / log）时替换为结构化日志。

既有后续项仍保留：

• controlplane::Authority::lookup_prefix / locate clone BlockMeta，按 P7 性能校准处理。