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 版本策略明确

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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