bug: pipedv1 deployment store returns newest deployment as head, not oldest
维护者通常 2 天内回复
还没有人认领这个 Issue。
- #6921 来自 @AruneshDwivedi —— 已关闭，未合并
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- go
- 领域
- devops, infrastructure
调研方向
从 pkg/app/pipedv1/apistore/deploymentstore/store.go:125-134 中的 ListAppHeadDeployments 以及 pkg/app/piped/apistore/deploymentstore/store.go 中对应的实现开始。跟踪该方法的使用位置，以确定 head 应该是最早的还是最新的未完成 deployment，然后为两个 store 添加 issue 中描述的双 deployment 回归测试。当实现与 Lister 的 docstring 一致时即完成。
由索引模型根据 Issue 内容生成。
描述
What happened:
While reviewing the deployment store sync logic in pipedv1, the head-deployment selection in pkg/app/pipedv1/apistore/deploymentstore/store.go:125-134 looks inverted relative to the Lister interface's docstring.
The interface promises:
ListAppHeadDeploymentsreturns the map from application ID to its head of deploying deployments.
Head deployment is same with the oldest uncompleted one.
But the implementation writes pendings → planneds → runnings into the same map[string]*model.Deployment, so for an application with both a pending and a running deployment, the running one wins by overwrite order:
for _, d := range pendings { headDeployments[d.ApplicationId] = d }
for _, d := range planneds { headDeployments[d.ApplicationId] = d }
for _, d := range runnings { headDeployments[d.ApplicationId] = d }
A PENDING deployment is logically newer than a RUNNING one for the same application (it was created later, after the running one started), so this code returns the newest uncompleted deployment, not the oldest.
The same inversion exists at the corresponding location in the v0 store (pkg/app/piped/apistore/deploymentstore/store.go).
What you expected to happen:
Either:
- The docstring is updated to match the implementation ("head = newest uncompleted"), or
- The implementation is corrected to match the docstring — either reverse the write order or pick the head explicitly by
created_at.
I don't know which side is correct, since I haven't traced where ListAppHeadDeployments is consumed downstream. Whichever way it ends up, the docstring and the code should agree.
How to reproduce it:
Unit test against the store with two *model.Deployment instances sharing one ApplicationId, one DEPLOYMENT_PENDING and one DEPLOYMENT_RUNNING. Lister.ListAppHeadDeployments()[appID] returns the running one — the opposite of what the docstring promises.
Environment:
pipedversion: master @78fdbeb7c(both v0 and v1 affected)control-planeversion: same- Others: surfaced during self-review of #6727 while writing tests for
ListAppHeadDeployments
- 主要语言
- Go
- 星标
- 1.4k
- 派生
- 391
- 平均合并
- 4 天 1 小时
- 30 天内合并 PR
- 58
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
pipe-cd/pipecd 的其他 Issue
-
Applications at the repository root are not triggered by new commits可能已有人在做 @Daksha1611 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 2 天内回复
-
pipedv1 kubernetes plugins ignore trafficRouting.istio.host in K8S_TRAFFIC_ROUTING可能已有人在做 @Dhirenderchoudhary 今天认领。 未关闭
难度 2/5 半天 新手友好度 74/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 2 天内回复
-
pipectl transfer restore application drops backed-up labels可能已有人在做 @bhavishyajain545 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 83/100
维护者通常 2 天内回复
相似的 Issue
-
needs-triage typo
难度 1/5 1 小时以内 新手友好度 88/100
llm-d-incubation/llm-d-scaling-manager#122 ·
维护者通常 1 天内回复
-
good first issue severity: low tech-debt
难度 2/5 半天 新手友好度 75/100
TMHSDigital/subenum#329 ·
维护者通常 1 天内回复
-
[Bug] Backend summarize min() / max() panics when a field has no numeric values可能已有人在做 @weng5e 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 64/100
grafana/grafana-infinity-datasource#1832 ·
维护者通常 1 天内回复
-
tech-debt
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
GillMacedo/godebugdiff#13 ·