bug: pipedv1 deployment store returns newest deployment as head, not oldest
Maintainer thường phản hồi trong vòng 2 ngày
Chưa có ai nhận issue này.
- #6921 của @AruneshDwivedi — đã đóng, không merge
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- go
- Lĩnh vực
- devops, infrastructure
Hướng nghiên cứu
Bắt đầu với ListAppHeadDeployments trong pkg/app/pipedv1/apistore/deploymentstore/store.go:125-134 và phần triển khai tương ứng trong pkg/app/piped/apistore/deploymentstore/store.go. Truy vết nơi phương thức được sử dụng để xác định head nên là deployment chưa hoàn tất cũ nhất hay mới nhất, sau đó thêm regression test với hai deployment được mô tả trong issue cho cả hai store. Hoàn tất khi phần triển khai và docstring của Lister thống nhất với nhau.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Go
- Star
- 1.4k
- Fork
- 391
- Merge trung bình
- 4 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 58
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của pipe-cd/pipecd
-
Applications at the repository root are not triggered by new commitsCó thể đã có người làm @Daksha1611 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 2 ngày
-
pipedv1 kubernetes plugins ignore trafficRouting.istio.host in K8S_TRAFFIC_ROUTINGCó thể đã có người làm @Dhirenderchoudhary đã nhận hôm nay. Đang mở
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 74/100
pipe-cd/pipecd#7626 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 2 ngày
-
pipectl transfer restore application drops backed-up labelsCó thể đã có người làm @bhavishyajain545 đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
pipe-cd/pipecd#7622 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của pipe-cd/pipecd
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
docker-compose: postgres healthcheck should probe TCP (pg_isready -h localhost)Có thể đã có người làm @zezo-mohamed22 đã nhận hôm nay. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
OneBusAway/watchdog#305 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
self-care self-care:agent-discoverability
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
githubnext/gh-cao#20928 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
automation documentation
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
SocialGouv/iterion#3287 ·
Maintainer thường phản hồi trong vòng 1 ngày