Skip to content

review: PR #3 (CLIv0.2.0) 遗留问题清单 #4

Description

@Guo-Zhang

背景

对 PR #3 (CLIv0.2.0) 合并后的代码做了完整 review + 构建测试(CLI 74 测试、Provider 5 包全部通过)。以下为非阻塞改进项,供 v0.3.0 或后续迭代处理。

问题清单

1. 重复工具函数应抽取公共模块(中优先级)

catalog.rstransfer.rsprocess.rs 各自复制了 chrono_now() / days_to_date() / sanitize_id() 实现(Go 侧 sanitizeID 同理)。三处行为一致,但后续改动易漂移。

建议:CLI 抽 src/util.rs(或 common.rs)统一放置时间/ID 工具函数;Provider 侧同样抽到内部公共包。

2. store.go SaveJob 的克隆语义(低优先级,需确认)

Store.SaveJob 内部 cloneJob 后存储,GetJob/ListJobs 返回克隆。handler.goRunBlueprint 流程是:先 SaveJob(running) → 执行 → 改 job 字段 → 再 SaveJob。逻辑正确,但依赖"每次 SaveJob 都完整序列化最新状态"这一约定,后续若有人直接改 GetJob 返回值的字段会静默丢失。

建议:加注释明确"返回值是副本,修改需重新 SaveJob",或在 handler 中显式重建记录。

3. ResolvePipeline 仍是 TODO(信息同步)

src/provider/internal/pipeline/pipeline.goResolvePipeline 依旧返回 TODO: CUE integration(旧代码如此,非本次回归)。但 src/cli/README.mdROADMAP.md 描述了 CUE 集成能力,容易造成预期偏差。

建议:要么落地 CUE 集成,要么在文档中标注"Provider 侧 pipeline 解析为 TODO"。

4. Go toolchain 固定 go 1.26.4 影响构建(环境问题)

go.mod 固定 go 1.26.4,本地若只有 1.26.0 会强制从 proxy.golang.org 下载 toolchain;国内网络环境不通时会直接构建失败(本地需切 GOPROXY=https://goproxy.cn 解决)。

建议:评估是否必须固定 1.26.4;若无需新特性可放宽到 go 1.26,或 CI 中配置 GOPROXY 镜像。

验收标准

  • 抽取公共工具模块(CLI + Provider)
  • store 克隆语义补充注释或重构
  • ResolvePipeline TODO 落地或文档标注
  • Go toolchain 版本策略明确

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions